aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-15tests/unit/test-smp-parse: Restore MachineClass fields after modifyingPhilippe Mathieu-Daudé1-1/+9
There is a single MachineClass object, registered with type_register_static(&smp_machine_info). Since the same object is used multiple times (an MachineState object is instantiated in both test_generic and test_with_dies), we should restore its internal state after modifying for the test purpose. Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Tested-by: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211115145900.2531865-2-philmd@redhat.com>
2021-11-15hw/rtc/pl031: Send RTC_CHANGE QMP eventEric Auger2-2/+10
The PL031 currently is not able to report guest RTC change to the QMP monitor as opposed to mc146818 or spapr RTCs. This patch adds the call to qapi_event_send_rtc_change() when the Load Register is written. The value which is reported corresponds to the difference between the guest reference time and the reference time kept in softmmu/rtc.c. For instance adding 20s to the guest RTC value will report 20. Adding an extra 20s to the guest RTC value will report 20 + 20 = 40. The inclusion of qapi/qapi-types-misc-target.h in hw/rtl/pl031.c require to compile the PL031 with specific_ss.add() to avoid ./qapi/qapi-types-misc-target.h:18:13: error: attempt to use poisoned "TARGET_<ARCH>". Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210920122535.269988-1-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-11-15hw/intc/arm_gicv3: Support multiple redistributor regionsPeter Maydell5-31/+46
Our GICv3 QOM interface includes an array property redist-region-count which allows board models to specify that the registributor registers are not in a single contiguous range, but split into multiple pieces. We implemented this for KVM, but currently the TCG GICv3 model insists that there is only one region. You can see the limit being hit with a setup like: qemu-system-aarch64 -machine virt,gic-version=3 -smp 124 Add support for split regions to the TCG GICv3. To do this we switch from allocating a simple array of MemoryRegions to an array of GICv3RedistRegion structs so that we can use the GICv3RedistRegion as the opaque pointer in the MemoryRegion read/write callbacks. Each GICv3RedistRegion contains the MemoryRegion, a backpointer allowing the read/write callback to get hold of the GICv3State, and an index which allows us to calculate which CPU's redistributor is being accessed. Note that arm_gicv3_kvm always passes in NULL as the ops argument to gicv3_init_irqs_and_mmio(), so the only MemoryRegion read/write callbacks we need to update to handle this new scheme are the gicv3_redist_read/write functions used by the emulated GICv3. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-15hw/intc/arm_gicv3: Set GICR_TYPER.Last correctly when nb_redist_regions > 1Peter Maydell1-5/+12
The 'Last' bit in the GICR_TYPER GICv3 redistributor register is supposed to be set to 1 if this is the last redistributor in a series of contiguous redistributor pages. Currently we set Last only for the redistributor for CPU (num_cpu - 1). This only works if there is a single redistributor region; if there are multiple redistributor regions then we need to set the Last bit for the last redistributor in each region. This doesn't cause any problems currently because only the KVM GICv3 supports multiple redistributor regions, and it ignores the value in GICv3State::gicr_typer. But we need to fix this before we can enable support for multiple regions in the emulated GICv3. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-15hw/intc/arm_gicv3: Move checking of redist-region-count to ↵Peter Maydell4-24/+16
arm_gicv3_common_realize The GICv3 devices have an array property redist-region-count. Currently we check this for errors (bad values) in gicv3_init_irqs_and_mmio(), just before we use it. Move this error checking to the arm_gicv3_common_realize() function, where we sanity-check all of the other base-class properties. (This will always be before gicv3_init_irqs_and_mmio() is called, because that function is called in the subclass realize methods, after they have called the parent-class realize.) The motivation for this refactor is: * we would like to use the redist_region_count[] values in arm_gicv3_common_realize() in a subsequent patch, so we need to have already done the sanity-checking first * this removes the only use of the Error** argument to gicv3_init_irqs_and_mmio(), so we can remove some error-handling boilerplate Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-15pcie: expire pending deleteGerd Hoffmann3-1/+6
Add an expire time for pending delete, once the time is over allow pressing the attention button again. This makes pcie hotplug behave more like acpi hotplug, where one can try sending an 'device_del' monitor command again in case the guest didn't respond to the first attempt. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-7-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pcie: fast unplug when slot power is offGerd Hoffmann1-0/+10
In case the slot is powered off (and the power indicator turned off too) we can unplug right away, without round-trip to the guest. Also clear pending attention button press, there is nothing to care about any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-6-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pcie: factor out pcie_cap_slot_unplug()Gerd Hoffmann1-12/+20
No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-5-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pcie: add power indicator blink checkGerd Hoffmann1-0/+7
Refuse to push the attention button in case the guest is busy with some hotplug operation (as indicated by the power indicator blinking). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-4-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pcie: implement slot power control for pcie root portsGerd Hoffmann1-0/+28
With this patch hot-plugged pci devices will only be visible to the guest if the guests hotplug driver has enabled slot power. This should fix the hot-plug race which one can hit when hot-plugging a pci device at boot, while the guest is in the middle of the pci bus scan. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-3-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pci: implement power stateGerd Hoffmann3-4/+29
This allows to power off pci devices. In "off" state the devices will not be visible. No pci config space access, no pci bar access, no dma. Default state is "on", so this patch (alone) should not change behavior. Use case: Allows hotplug controllers implement slot power. Hotplug controllers doing so should set the inital power state for devices in the ->plug callback. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20211111130859.1171890-2-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15vdpa: Check for existence of opts.vhostdevEugenio Pérez1-0/+4
Since net_init_vhost_vdpa is trying to open it. Not specifying it in the command line crash qemu. Fixes: 7327813d17 ("vhost-vdpa: open device fd in net_init_vhost_vdpa()") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20211112193431.2379298-3-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15vdpa: Replace qemu_open_old by qemu_open atEugenio Pérez1-1/+1
There is no reason to keep using the old one, since we neither use the variadics arguments nor open it with O_DIRECT. Also, net_client_init1, the caller of net_init_vhost_vdpa, wants all net_client_init_fun to use Error API, so it's a good step in that direction. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20211112193431.2379298-2-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15virtio: use virtio accessor to access packed eventJason Wang1-9/+4
We used to access packed descriptor event and off_wrap via address_space_{write|read}_cached(). When we hit the cache, memcpy() is used which is not atomic which may lead a wrong value to be read or wrote. This patch fixes this by switching to use virito_{stw|lduw}_phys_cached() to make sure the access is atomic. Fixes: 683f7665679c1 ("virtio: event suppression support for packed ring") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211111063854.29060-2-jasowang@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15virtio: use virtio accessor to access packed descriptor flagsJason Wang1-7/+4
We used to access packed descriptor flags via address_space_{write|read}_cached(). When we hit the cache, memcpy() is used which is not an atomic operation which may lead a wrong value is read or wrote. So this patch switches to use virito_{stw|lduw}_phys_cached() to make sure the aceess is atomic. Fixes: 86044b24e865f ("virtio: basic packed virtqueue support") Cc: qemu-stable@nongnu.org Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211111063854.29060-1-jasowang@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15tests: bios-tables-test update expected blobsIgor Mammedov16-16/+0
The changes are the result of 'hw/i386/acpi-build: Deny control on PCIe Native Hot-Plug in _OSC' which hides PCIE hotplug bit in host-bridge _OSC Method (_OSC, 4, NotSerialized) // _OSC: Operating System Capabilities { CreateDWordField (Arg3, Zero, CDW1) If ((Arg0 == ToUUID ("33db4d5b-1ff7-401c-9657-7441c03dd766") /* PCI Host Bridge Device */)) { CreateDWordField (Arg3, 0x04, CDW2) CreateDWordField (Arg3, 0x08, CDW3) Local0 = CDW3 /* \_SB_.PCI0._OSC.CDW3 */ - Local0 &= 0x1F + Local0 &= 0x1E Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20211112110857.3116853-6-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15hw/i386/acpi-build: Deny control on PCIe Native Hot-plug in _OSCJulia Suvorova1-4/+8
There are two ways to enable ACPI PCI Hot-plug: * Disable the Hot-plug Capable bit on PCIe slots. This was the first approach which led to regression [1-2], as I/O space for a port is allocated only when it is hot-pluggable, which is determined by HPC bit. * Leave the HPC bit on and disable PCIe Native Hot-plug in _OSC method. This removes the (future) ability of hot-plugging switches with PCIe Native hotplug since ACPI PCI Hot-plug only works with cold-plugged bridges. If the user wants to explicitely use this feature, they can disable ACPI PCI Hot-plug with: --global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off Change the bit in _OSC method so that the OS selects ACPI PCI Hot-plug instead of PCIe Native. [1] https://gitlab.com/qemu-project/qemu/-/issues/641 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006409 Signed-off-by: Julia Suvorova <jusual@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20211112110857.3116853-5-imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15bios-tables-test: Allow changes in DSDT ACPI tablesJulia Suvorova1-0/+16
Prepare for changing the _OSC method in q35 DSDT. Signed-off-by: Julia Suvorova <jusual@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20211112110857.3116853-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15hw/acpi/ich9: Add compat prop to keep HPC bit set for 6.1 machine typeJulia Suvorova4-1/+27
To solve issues [1-2] the Hot Plug Capable bit in PCIe Slots will be turned on, while the switch to ACPI Hot-plug will be done in the DSDT table. Introducing 'x-keep-native-hpc' property disables the HPC bit only in 6.1 and as a result keeps the forced 'reserve-io' on pcie-root-ports in 6.1 too. [1] https://gitlab.com/qemu-project/qemu/-/issues/641 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2006409 Signed-off-by: Julia Suvorova <jusual@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20211112110857.3116853-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-15pcie: rename 'native-hotplug' to 'x-native-hotplug'Igor Mammedov2-2/+2
Mark property as experimental/internal adding 'x-' prefix. Property was introduced in 6.1 and it should have provided ability to turn on native PCIE hotplug on port even when ACPI PCI hotplug is in use is user explicitly sets property on CLI. However that never worked since slot is wired to ACPI hotplug controller. Another non-intended usecase: disable native hotplug on slot when APCI based hotplug is disabled, which works but slot has 'hotplug' property for this taks. It should be relatively safe to rename it to experimental as no users should exist for it and given that the property is broken we don't really want to leave it around for much longer lest users start using it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20211112110857.3116853-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-12Merge tag 'pull-ppc-20211112' of https://github.com/legoater/qemu into stagingRichard Henderson3-33/+33
ppc 6.2 queue : * Fix of a regression in floating point load instructions (Matheus) * Associativity fix for pseries machine (Daniel) * tlbivax fix for BookE machines (Danel) # gpg: Signature made Fri 12 Nov 2021 12:11:29 PM CET # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-ppc-20211112' of https://github.com/legoater/qemu: ppc/mmu_helper.c: do not truncate 'ea' in booke206_invalidate_ea_tlb() spapr_numa.c: fix FORM1 distance-less nodes target/ppc: Fix register update on lf[sd]u[x]/stf[sd]u[x] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11Merge tag 'pull-tcg-20211111' of https://gitlab.com/rth7680/qemu into stagingRichard Henderson7-11/+19
appease coverity vs extract2 update docs for ctpop opcodes tcg/s390x build fix for gcc11 # gpg: Signature made Thu 11 Nov 2021 12:05:20 PM CET # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate] * tag 'pull-tcg-20211111' of https://gitlab.com/rth7680/qemu: tcg/s390x: Fix tcg_out_vec_op argument type tcg: Document ctpop opcodes tcg: Remove TCI experimental status tcg/optimize: Add an extra cast to fold_extract2 Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11tcg/s390x: Fix tcg_out_vec_op argument typeMiroslav Rezanina1-1/+2
Newly defined tcg_out_vec_op (34ef767609 tcg/s390x: Add host vector framework) for s390x uses pointer argument definition. This fails on gcc 11 as original declaration uses array argument: In file included from ../tcg/tcg.c:430: /builddir/build/BUILD/qemu-6.1.50/tcg/s390x/tcg-target.c.inc:2702:42: error: argument 5 of type 'const TCGArg *' {aka 'const long unsigned int *'} declared as a pointer [-Werror=array-parameter=] 2702 | const TCGArg *args, const int *const_args) | ~~~~~~~~~~~~~~^~~~ ../tcg/tcg.c:121:41: note: previously declared as an array 'const TCGArg[16]' {aka 'const long unsigned int[16]'} 121 | const TCGArg args[TCG_MAX_OP_ARGS], | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ In file included from ../tcg/tcg.c:430: /builddir/build/BUILD/qemu-6.1.50/tcg/s390x/tcg-target.c.inc:2702:59: error: argument 6 of type 'const int *' declared as a pointer [-Werror=array-parameter=] 2702 | const TCGArg *args, const int *const_args) | ~~~~~~~~~~~^~~~~~~~~~ ../tcg/tcg.c:122:38: note: previously declared as an array 'const int[16]' 122 | const int const_args[TCG_MAX_OP_ARGS]); | ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixing argument type to pass build. Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <20211027085629.240704-1-mrezanin@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11tcg: Document ctpop opcodesRichard Henderson1-0/+6
Fixes: a768e4e99247 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/658 Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11tcg: Remove TCI experimental statusPhilippe Mathieu-Daudé4-9/+10
The following commits (released in v6.0.0) made raised the quality of the TCI backend to the other TCG architectures, thus is is not considerated experimental anymore: - c6fbea47664..2f74f45e32b - dc09f047edd..9e9acb7b348 - b6139eb0578..2fc6f16ca5e - dbcbda2cd84..5e8892db93f Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211106111457.517546-1-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11tcg/optimize: Add an extra cast to fold_extract2Richard Henderson1-1/+1
There is no bug, but silence a warning about computation in int32_t being assigned to a uint64_t. Reported-by: Coverity CID 1465220 Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11ppc/mmu_helper.c: do not truncate 'ea' in booke206_invalidate_ea_tlb()Daniel Henrique Barboza1-1/+1
'tlbivax' is implemented by gen_tlbivax_booke206() via gen_helper_booke206_tlbivax(). In case the TLB needs to be flushed, booke206_invalidate_ea_tlb() is called. All these functions, but booke206_invalidate_ea_tlb(), uses a 64-bit effective address 'ea'. booke206_invalidate_ea_tlb() uses an uint32_t 'ea' argument that truncates the original 'ea' value for apparently no particular reason. This function retrieves the tlb pointer by calling booke206_get_tlbm(), which also uses a target_ulong address as parameter - in this case, a truncated 'ea' address. All the surrounding logic considers the effective TLB address as a 64 bit value, aside from the signature of booke206_invalidate_ea_tlb(). Last but not the least, PowerISA 2.07B section 6.11.4.9 [2] makes it clear that the effective address "EA" is a 64 bit value. Commit 01662f3e5133 introduced this code and no changes were made ever since. An user detected a problem with tlbivax [1] stating that this address truncation was the cause. This same behavior might be the source of several subtle bugs that were never caught. For all these reasons, this patch assumes that this address truncation is the result of a mistake/oversight of the original commit, and changes booke206_invalidate_ea_tlb() 'ea' argument to 'vaddr'. [1] https://gitlab.com/qemu-project/qemu/-/issues/52 [2] https://wiki.raptorcs.com/wiki/File:PowerISA_V2.07B.pdf Fixes: 01662f3e5133 ("PPC: Implement e500 (FSL) MMU") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/52 Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-11Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingRichard Henderson7-0/+128
* Fixes for SGX * force_rcu notifiers # gpg: Signature made Wed 10 Nov 2021 10:57:48 PM CET # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: sgx: Reset the vEPC regions during VM reboot numa: avoid crash with SGX and "info numa" accel/tcg: Register a force_rcu notifier rcu: Introduce force_rcu notifier target/i386: sgx: mark device not user creatable Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-11hw/mem/pc-dimm: Restrict NUMA-specific code to NUMA machinesPhilippe Mathieu-Daudé1-8/+15
When trying to use the pc-dimm device on a non-NUMA machine, we get: $ qemu-system-arm -M none -cpu max -S \ -object memory-backend-file,id=mem1,size=1M,mem-path=/tmp/1m \ -device pc-dimm,id=dimm1,memdev=mem1 Segmentation fault (core dumped) (gdb) bt #0 pc_dimm_realize (dev=0x555556da3e90, errp=0x7fffffffcd10) at hw/mem/pc-dimm.c:184 #1 0x0000555555fe1f8f in device_set_realized (obj=0x555556da3e90, value=true, errp=0x7fffffffce18) at hw/core/qdev.c:531 #2 0x0000555555feb4a9 in property_set_bool (obj=0x555556da3e90, v=0x555556e54420, name=0x5555563c3c41 "realized", opaque=0x555556a704f0, errp=0x7fffffffce18) at qom/object.c:2257 To avoid that crash, restrict the pc-dimm NUMA check to machines supporting NUMA, and do not allow the use of 'node' property on non-NUMA machines. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211106145016.611332-1-f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-11vhost: Fix last vq queue index of devices with no cvqEugenio Pérez1-4/+4
The -1 assumes that cvq device model is accounted in data_queue_pairs, if cvq does not exists, but it's actually the opposite: Devices with !cvq are ok but devices with cvq does not add the last queue to data_queue_pairs. This is not a problem to vhost-net, but it is to vhost-vdpa: * Devices with cvq gets initialized at last data vq device model, not at cvq one. * Devices with !cvq never gets initialized, since last_index is the first queue of the last device model. Because of that, the right change in last_index is to actually add the cvq, not to remove the missing one. This is not a problem to vhost-net, but it is to vhost-vdpa, which device model trust to reach the last index to finish starting the device. Also, as the previous commit, rename it to index_end. Tested with vp_vdpa with host's vhost=on and vhost=off, with ctrl_vq=on and ctrl_vq=off. Fixes: 049eb15b5fc9 ("vhost: record the last virtqueue index for the virtio device") Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20211104085625.2054959-3-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-11vhost: Rename last_index to vq_index_endEugenio Pérez3-5/+5
The doc of this field pointed out that last_index is the last vq index. This is misleading, since it's actually one past the end of the vqs. Renaming and modifying comment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211104085625.2054959-2-eperezma@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-11softmmu/qdev-monitor: fix use-after-free in qdev_set_id()Stefan Hajnoczi1-1/+1
Reported by Coverity (CID 1465222). Fixes: 4a1d937796de0fecd8b22d7dbebf87f38e8282fd ("softmmu/qdev-monitor: add error handling in qdev_set_id") Cc: Damien Hedde <damien.hedde@greensocs.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211102163342.31162-1-stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2021-11-11net/vhost-vdpa: fix memory leak in vhost_vdpa_get_max_queue_pairs()Stefano Garzarella1-1/+1
Use g_autofree to ensure that `config` is freed when vhost_vdpa_get_max_queue_pairs() returns. Reported-by: Coverity (CID 1465228: RESOURCE_LEAK) Fixes: 402378407d ("vhost-vdpa: multiqueue support") Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20211102155157.241034-1-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2021-11-10sgx: Reset the vEPC regions during VM rebootYang Zhong1-0/+50
For bare-metal SGX on real hardware, the hardware provides guarantees SGX state at reboot. For instance, all pages start out uninitialized. The vepc driver provides a similar guarantee today for freshly-opened vepc instances, but guests such as Windows expect all pages to be in uninitialized state on startup, including after every guest reboot. Qemu can invoke the ioctl to bring its vEPC pages back to uninitialized state. There is a possibility that some pages fail to be removed if they are SECS pages, and the child and SECS pages could be in separate vEPC regions. Therefore, the ioctl returns the number of EREMOVE failures, telling Qemu to try the ioctl again after it's done with all vEPC regions. The related kernel patches: Link: https://lkml.kernel.org/r/20211021201155.1523989-3-pbonzini@redhat.com Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20211101162009.62161-6-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-10spapr_numa.c: fix FORM1 distance-less nodesDaniel Henrique Barboza1-31/+31
Commit 71e6fae3a99 fixed an issue with FORM2 affinity guests with NUMA nodes in which the distance info is absent in machine_state->numa_state->nodes. This happens when QEMU adds a default NUMA node and when the user adds NUMA nodes without specifying the distances. During the discussions of the forementioned patch [1] it was found that FORM1 guests were behaving in a strange way in the same scenario, with the kernel seeing the distances between the nodes as '160', as we can see in this example with 4 NUMA nodes without distance information: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 160 160 160 1: 160 10 160 160 2: 160 160 10 160 3: 160 160 160 10 Turns out that we have the same problem with FORM1 guests - we are calculating associativity domain using zeroed values. And as it also turns out, the solution from 71e6fae3a99 applies to FORM1 as well. This patch creates a wrapper called 'get_numa_distance' that contains the logic used in FORM2 to define node distances when this information is absent. This helper is then used in all places where we need to read distance information from machine_state->numa_state->nodes. That way we'll guarantee that the NUMA node distance is always being curated before being used. After this patch, the FORM1 guest mentioned above will have the following topology: $ numactl -H available: 4 nodes (0-3) (...) node distances: node 0 1 2 3 0: 10 20 20 20 1: 20 10 20 20 2: 20 20 10 20 3: 20 20 20 10 This is compatible with what FORM2 guests and other archs do in this case. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg01960.html Fixes: 690fbe4295d5 ("spapr_numa: consider user input when defining associativity") CC: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> CC: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-10numa: avoid crash with SGX and "info numa"Paolo Bonzini1-0/+7
Add the MEMORY_DEVICE_INFO_KIND_SGX_EPC case, so that enclave memory is included in the output of "info numa" instead of crashing the monitor. Fixes: a7c565a941 ("sgx-epc: Add the fill_device_info() callback support", 2021-09-30) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-10accel/tcg: Register a force_rcu notifierGreg Kurz2-0/+36
A TCG vCPU doing a busy loop systematicaly hangs the QEMU monitor if the user passes 'device_add' without argument. This is because drain_cpu_all() which is called from qmp_device_add() cannot return if readers don't exit read-side critical sections. That is typically what busy-looping TCG vCPUs do: int cpu_exec(CPUState *cpu) { [...] rcu_read_lock(); [...] while (!cpu_handle_exception(cpu, &ret)) { // Busy loop keeps vCPU here } [...] rcu_read_unlock(); return ret; } For MTTCG, have all vCPU threads register a force_rcu notifier that will kick them out of the loop using async_run_on_cpu(). The notifier is called with the rcu_registry_lock mutex held, using async_run_on_cpu() ensures there are no deadlocks. For RR, a single thread runs all vCPUs. Just register a single notifier that kicks the current vCPU to the next one. For MTTCG: Suggested-by: Paolo Bonzini <pbonzini@redhat.com> For RR: Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: 7bed89958bfb ("device_core: use drain_call_rcu in in qmp_device_add") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/650 Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211109183523.47726-3-groug@kaod.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-10rcu: Introduce force_rcu notifierGreg Kurz2-0/+34
The drain_rcu_call() function can be blocked as long as an RCU reader stays in a read-side critical section. This is typically what happens when a TCG vCPU is executing a busy loop. It can deadlock the QEMU monitor as reported in https://gitlab.com/qemu-project/qemu/-/issues/650 . This can be avoided by allowing drain_rcu_call() to enforce an RCU grace period. Since each reader might need to do specific actions to end a read-side critical section, do it with notifiers. Prepare ground for this by adding a notifier list to the RCU reader struct and use it in wait_for_readers() if drain_rcu_call() is in progress. An API is added for readers to register their notifiers. This is largely based on a draft from Paolo Bonzini. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211109183523.47726-2-groug@kaod.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-10Merge tag 'pull-qapi-2021-11-10' of git://repo.or.cz/qemu/armbru into stagingRichard Henderson2-23/+60
QAPI patches patches for 2021-11-10 # gpg: Signature made Wed 10 Nov 2021 06:21:23 AM CET # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] * tag 'pull-qapi-2021-11-10' of git://repo.or.cz/qemu/armbru: qapi: Belatedly mark unstable QMP parts with feature 'unstable' docs/devel/qapi-code-gen: Belatedly document feature documentation docs/devel/qapi-code-gen: Drop a duplicate paragraph Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-10Merge tag 'pull-monitor-2021-11-10' of git://repo.or.cz/qemu/armbru into stagingRichard Henderson3-7/+24
Monitor patches patches for 2021-11-10 # gpg: Signature made Wed 10 Nov 2021 06:15:38 AM CET # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] * tag 'pull-monitor-2021-11-10' of git://repo.or.cz/qemu/armbru: monitor: Fix find_device_state() for IDs containing slashes Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-10target/ppc: Fix register update on lf[sd]u[x]/stf[sd]u[x]Matheus Ferst1-1/+1
These instructions should update the GPR indicated by the field RA instead of RT. This error caused a regression on Mac OS 9 boot and some graphical glitches in OS X. Fixes: a39a106634a9 ("target/ppc: Move load and store floating point instructions to decodetree") Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-10monitor: Fix find_device_state() for IDs containing slashesMarkus Armbruster3-7/+24
Recent commit 6952026120 "monitor: Tidy up find_device_state()" assumed the function's argument is "the device's ID or QOM path" (as documented for device_del). It's actually either an absolute QOM path, or a QOM path relative to /machine/peripheral/. Such a relative path is a device ID when it doesn't contain a slash. When it does, the function now always fails. Broke iotest 200, which uses relative path "vda/virtio-backend". It fails because object_resolve_path_component() resolves just one component, not a relative path. The obvious function to resolve relative paths is object_resolve_path(). It picks a parent automatically. Too much magic, we want to specify the parent. Create new object_resolve_path_at() for that, and use it in find_device_state(). Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211019085711.86377-1-armbru@redhat.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-10qapi: Belatedly mark unstable QMP parts with feature 'unstable'Markus Armbruster1-9/+45
The work in merge commit e86e00a2493 lacks special feature flag 'unstable', because it raced with it. Add it where it's missing. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211109145559.2122827-1-armbru@redhat.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-11-10docs/devel/qapi-code-gen: Belatedly document feature documentationMarkus Armbruster1-8/+15
Commit 6a8c0b5102 "qapi: Add feature flags to struct types" neglected to document how to document feature flags. Make up for that. Cc: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211026111023.76937-3-armbru@redhat.com> [Editing accident fixed]
2021-11-10docs/devel/qapi-code-gen: Drop a duplicate paragraphMarkus Armbruster1-6/+0
Commit 55ec69f8b1 "docs/devel/qapi-code-gen.txt: Update to new rST backend conventions" accidentally duplicated a paragraph. Drop it. Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211026111023.76937-2-armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2021-11-09Merge tag 'pull-jobs-2021-11-09' of ↵Richard Henderson6-90/+268
https://src.openvz.org/scm/~vsementsov/qemu into staging qmp: deprecate drive-backup (use blockdev-backup instead) # gpg: Signature made Tue 09 Nov 2021 06:43:31 PM CET # gpg: using RSA key 8B9C26CDB2FD147C880E86A1561F24C1F19F79FB # gpg: Good signature from "Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 8B9C 26CD B2FD 147C 880E 86A1 561F 24C1 F19F 79FB * tag 'pull-jobs-2021-11-09' of https://src.openvz.org/scm/~vsementsov/qemu: qapi: deprecate drive-backup docs/interop/bitmaps: use blockdev-backup docs/block-replication: use blockdev-backup Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-09target/i386: sgx: mark device not user creatablePaolo Bonzini1-0/+1
The device is created by the machine based on the sgx-epc property. It should not be created by users. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-09Update version for v6.2.0-rc0 releasev6.2.0-rc0Richard Henderson1-1/+1
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-09qapi: deprecate drive-backupVladimir Sementsov-Ogievskiy4-18/+51
Modern way is using blockdev-add + blockdev-backup, which provides a lot more control on how target is opened. As example of drive-backup problems consider the following: User of drive-backup expects that target will be opened in the same cache and aio mode as source. Corresponding logic is in drive_backup_prepare(), where we take bs->open_flags of source. It works rather bad if source was added by blockdev-add. Assume source is qcow2 image. On blockdev-add we should specify aio and cache options for file child of qcow2 node. What happens next: drive_backup_prepare() looks at bs->open_flags of qcow2 source node. But there no BDRV_O_NOCAHE neither BDRV_O_NATIVE_AIO: BDRV_O_NOCAHE is places in bs->file->bs->open_flags, and BDRV_O_NATIVE_AIO is nowhere, as file-posix parse options and simply set s->use_linux_aio. The documentation is updated in a minimal way, so that drive-backup is noted only as a deprecated command, and blockdev-backup used in most of places. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2021-11-09docs/interop/bitmaps: use blockdev-backupVladimir Sementsov-Ogievskiy1-70/+215
We are going to deprecate drive-backup, so use modern interface here. In examples where target image creation is shown, show blockdev-add as well. If target creation omitted, omit blockdev-add as well. Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
generated by cgit v1.1 at 2025-02-15 05:15:57 +0000