Skip to content

Q
Qemu

mirror_resources / Qemu
11 个月 前同步成功

通知 4
Star 0
Fork 0
Q
Qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 6月, 2020 2 次提交
  3. 15 5月, 2020 1 次提交
    • M
      qom: Drop parameter @errp of object_property_add() & friends · d2623129
      由 Markus Armbruster 提交于 
      The only way object_property_add() can fail is when a property with
the same name already exists.  Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.

Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent.  Parentage is
also under program control, so this is a programming error, too.

We have a bit over 500 callers.  Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.

The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.

Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL.  Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call.  ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.

When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.

Drop parameter @errp and assert the preconditions instead.

There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification".  Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
      d2623129
  5. 06 5月, 2020 1 次提交
  7. 04 5月, 2020 1 次提交
  9. 09 3月, 2020 1 次提交
    • P
      hw/i386: Include "hw/mem/nvdimm.h" · 4b997690
      由 Philippe Mathieu-Daudé 提交于 
      All this files use methods/definitions declared in the NVDIMM
device header. Include it.

This fixes (when modifying unrelated headers):

  hw/i386/acpi-build.c:2733:9: error: implicit declaration of function 'nvdimm_build_acpi' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        nvdimm_build_acpi(table_offsets, tables_blob, tables->linker,
        ^
  hw/i386/pc.c:1996:61: error: use of undeclared identifier 'TYPE_NVDIMM'
    const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
                                                            ^
  hw/i386/pc.c:2032:55: error: use of undeclared identifier 'TYPE_NVDIMM'
    bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
                                                      ^
  hw/i386/pc.c:2040:9: error: implicit declaration of function 'nvdimm_plug' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        nvdimm_plug(ms->nvdimms_state);
        ^
  hw/i386/pc.c:2040:9: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
        nvdimm_plug(ms->nvdimms_state);
        ^
  hw/i386/pc.c:2065:42: error: use of undeclared identifier 'TYPE_NVDIMM'
    if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
                                         ^
  hw/i386/pc_i440fx.c:307:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
        ^
  hw/i386/pc_q35.c:332:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        nvdimm_init_acpi_state(machine->nvdimms_state, system_io,
        ^
Acked-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-Id: <20200228114649.12818-17-philmd@redhat.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
      4b997690
  11. 07 1月, 2020 1 次提交
  13. 05 1月, 2020 1 次提交
  15. 18 12月, 2019 1 次提交
  17. 14 12月, 2019 1 次提交
  19. 13 12月, 2019 1 次提交
    • E
      virtio-blk: advertise F_WCE (F_FLUSH) if F_CONFIG_WCE is advertised · 5f258577
      由 Evgeny Yakovlev 提交于 
      Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device
Initialization:

"Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if
they offer VIRTIO_BLK_F_CONFIG_WCE"

Currently F_CONFIG_WCE and F_WCE are not connected to each other.
Qemu will advertise F_CONFIG_WCE if config-wce argument is
set for virtio-blk device. And F_WCE is advertised only if
underlying block backend actually has it's caching enabled.

Fix this by advertising F_WCE if F_CONFIG_WCE is also advertised.

To preserve backwards compatibility with newer machine types make this
behaviour governed by "x-enable-wce-if-config-wce" virtio-blk-device
property and introduce hw_compat_4_2 with new property being off by
default for all machine types <= 4.2 (but don't introduce 4.3
machine type itself yet).
Signed-off-by: NEvgeny Yakovlev <wrfsh@yandex-team.ru>
Message-Id: <1572978137-189218-1-git-send-email-wrfsh@yandex-team.ru>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      5f258577
  21. 19 11月, 2019 1 次提交
    • L
      hw/i386: Move save_tsc_khz from PCMachineClass to X86MachineClass · 2f34ebf2
      由 Liam Merwick 提交于 
      Attempting to migrate a VM using the microvm machine class results in the source
QEMU aborting with the following message/backtrace:

target/i386/machine.c:955:tsc_khz_needed: Object 0x555556608fa0 is not an
instance of type generic-pc-machine

abort()
object_class_dynamic_cast_assert()
vmstate_save_state_v()
vmstate_save_state()
vmstate_save()
qemu_savevm_state_complete_precopy()
migration_thread()
migration_thread()
migration_thread()
qemu_thread_start()
start_thread()
clone()

The access to the machine class returned by MACHINE_GET_CLASS() in
tsc_khz_needed() is crashing as it is trying to dereference a different
type of machine class object (TYPE_PC_MACHINE) to that of this microVM.

This can be resolved by extending the changes in the following commit
f0bb276b ("hw/i386: split PCMachineState deriving X86MachineState from it")
and moving the save_tsc_khz field in PCMachineClass to X86MachineClass.

Fixes: f0bb276b ("hw/i386: split PCMachineState deriving X86MachineState from it")
Signed-off-by: NLiam Merwick <liam.merwick@oracle.com>
Reviewed-by: NDarren Kenny <darren.kenny@oracle.com>
Message-Id: <1574075605-25215-1-git-send-email-liam.merwick@oracle.com>
Reviewed-by: NSergio Lopez <slp@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2f34ebf2
  23. 26 10月, 2019 1 次提交
  25. 25 10月, 2019 1 次提交
  27. 24 10月, 2019 4 次提交
  29. 22 10月, 2019 4 次提交
  31. 21 9月, 2019 1 次提交
    • C
      pc: Add an SMB0 ACPI device to q35 · ebe15582
      由 Corey Minyard 提交于 
      This is so I2C devices can be found in the ACPI namespace.  Currently
that's only IPMI, but devices can be easily added now.

Adding the devices required some PCI information, and the bus itself
to be added to the PCMachineState structure.

Note that this only works on Q35, the ACPI for PIIX4 is not capable
of handling an SMBus device.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      ebe15582
  33. 21 8月, 2019 1 次提交
  35. 16 8月, 2019 3 次提交
  37. 06 7月, 2019 1 次提交
    • E
      i386: Make unversioned CPU models be aliases · 0788a56b
      由 Eduardo Habkost 提交于 
      This will make unversioned CPU models behavior depend on the
machine type:

* "pc-*-4.0" and older will not report them as aliases.
  This is done to keep compatibility with older QEMU versions
  after management software starts translating aliases.

* "pc-*-4.1" will translate unversioned CPU models to -v1.
  This is done to keep compatibility with existing management
  software, that still relies on CPU model runnability promises.

* "none" will translate unversioned CPU models to their latest
  version.  This is planned become the default in future machine
  types (probably in pc-*-4.3).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-8-ehabkost@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      0788a56b
  39. 21 6月, 2019 1 次提交
    • G
      hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1 · 8e8cbed0
      由 Greg Kurz 提交于 
      Commit c87759ce fixed a regression affecting pc-q35 machines by
introducing a new pc-q35-4.0.1 machine version to be used instead
of pc-q35-4.0. The only purpose was to revert the default behaviour
of not using split irqchip, but the change also introduced the usual
hw_compat and pc_compat bits, and wired them for pc-q35 only.

This raises questions when it comes to add new compat properties for
4.0* machine versions of any architecture. Where to add them ? In
4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach
all other architectures about 4.0.1. This solution isn't satisfying,
especially since this is a pc-q35 specific issue.

It turns out that the split irqchip default is handled in the machine
option function and doesn't involve compat lists at all.

Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1
machine option function.

Move the compat props that were added to the 4.0.1 since c87759ce to
4.0.

Even if only hw_compat_4_0_1 had an impact on other architectures,
drop pc_compat_4_0_1 as well for consistency.

Fixes: c87759ce "q35: Revert to kernel irqchip"
Suggested-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Message-Id: <156051774276.244890.8660277280145466396.stgit@bahia.lan>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8e8cbed0
  41. 03 6月, 2019 1 次提交
    • A
      q35: Revert to kernel irqchip · c87759ce
      由 Alex Williamson 提交于 
      Commit b2fc91db ("q35: set split kernel irqchip as default") changed
the default for the pc-q35-4.0 machine type to use split irqchip, which
turned out to have disasterous effects on vfio-pci INTx support.  KVM
resampling irqfds are registered for handling these interrupts, but
these are non-functional in split irqchip mode.  We can't simply test
for split irqchip in QEMU as userspace handling of this interrupt is a
significant performance regression versus KVM handling (GeForce GPUs
assigned to Windows VMs are non-functional without forcing MSI mode or
re-enabling kernel irqchip).

The resolution is to revert the change in default irqchip mode in the
pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable
branch.  The qemu-q35-4.0 machine type should not be used in vfio-pci
configurations for devices requiring legacy INTx support without
explicitly modifying the VM configuration to use kernel irqchip.

Link: https://bugs.launchpad.net/qemu/+bug/1826422
Fixes: b2fc91db ("q35: set split kernel irqchip as default")
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed-by: NPeter Xu <peterx@redhat.com>
Message-Id: <155786484688.13873.6037015630912983760.stgit@gimli.home>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c87759ce
  43. 26 4月, 2019 1 次提交
  45. 11 3月, 2019 1 次提交
  47. 28 2月, 2019 2 次提交
  49. 05 2月, 2019 1 次提交
  51. 08 1月, 2019 1 次提交
  53. 07 1月, 2019 4 次提交