aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2025-12-09Revert "hw/net/virtio-net: make VirtIONet.vlans an array instead of a pointer"Philippe Mathieu-Daudé1-4/+5
Per https://lore.kernel.org/qemu-devel/7798584d-e861-47b7-af52-2c2efb67a4de@proxmox.com/: Loading a VM state taken with v10.1.2 or older doesn't work anymore, using the script [*] we get: kvm: VQ 1 size 0x100 < last_avail_idx 0x9 - used_idx 0x3e30 kvm: load of migration failed: Operation not permitted: error while loading state for instance 0x0 of device '0000:00:13.0/virtio-net': Failed to load element of type virtio for virtio: -1 qemu-system-x86_64: Missing section footer for 0000:00:13.0/virtio-net qemu-system-x86_64: Section footer error, section_id: 41 [*]: #!/bin/bash rm /tmp/disk.qcow2 args=" -netdev type=tap,id=net1,ifname=tap104i1,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=BC:24:11:32:3C:69,netdev=net1,bus=pci.0,addr=0x13,id=net1 -machine type=pc-i440fx-10.1 " $1/qemu-img create -f qcow2 /tmp/disk.qcow2 1G $1/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args <<EOF {"execute": "qmp_capabilities"} {"execute": "snapshot-save", "arguments": { "job-id": "save0", "tag": "snap", "vmstate": "node0", "devices": ["node0"] } } {"execute": "quit"} EOF $2/qemu-system-x86_64 --qmp stdio --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 $args -loadvm snap This reverts commit 3a9cd2a4a1571266dea37398de04f650c2a72d86. Reported-by: Fiona Ebner <f.ebner@proxmox.com> Suggested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-12-09vhost: Always initialize cached vring dataHanna Czenczek1-15/+23
vhost_virtqueue_start() can exit early if the descriptor ring address is 0, assuming the virtqueue isn’t ready to start. In this case, all cached vring information (size, physical address, pointer) is left as-is. This is OK at first startup, when that info is still initialized to 0, but after a reset, it will retain old (outdated) information. vhost_virtqueue_start() must make sure these values are (re-)set properly before exiting. (When using an IOMMU, these outdated values can stall the device: vhost_dev_start() deliberately produces an IOMMU miss event for each used vring. If used_phys contains an outdated value, the resulting lookup may fail, forcing the device to be stopped.) Cc: qemu-stable@nongnu.org Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251208113008.153249-1-hreitz@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-12-09hw/9pfs: Correct typoAlano Song1-1/+1
Correct comment typo in xen_9pfs_bh() Signed-off-by: Alano Song <AlanoSong@163.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20251202132132.17636-1-AlanoSong@163.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-12-05aspeed: Deprecate the fby35 machineCédric Le Goater1-0/+1
There are no functional tests for the 'fby35' machine which makes harder to determine when something becomes deprecated or unused. The 'fby35' machine was originally added as an example of a multi-SoC system, with the expectation the models would evolve over time in an heterogeneous system. This hasn't happened and no public firmware is available to boot it. It can be replaced by the 'ast2700fc', another multi-SoC machine based on the newer AST2700 SoCs which are excepted to receive better support in the future. Cc: Peter Delevoryas <peter@pjd.dev> Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20251126102424.927527-1-clg@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2025-12-03vfio-user: recycle msg on failureJohn Levon1-5/+16
If we fail to read an incoming request, recycle the message. Resolves: Coverity CID 1611807 Resolves: Coverity CID 1611808 Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-6-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-12-03vfio-user: simplify vfio_user_recv_one()John Levon1-38/+30
This function was unnecessarily difficult to understand due to the separate handling of request and reply messages. Use common code for both where we can. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-5-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-12-03vfio-user: refactor out header handlingJohn Levon1-41/+60
Simplify vfio_user_recv_one() by moving the header handling out to a helper function. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-4-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-12-03vfio-user: clarify partial message handlingJohn Levon1-1/+4
Improve a comment for this. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-3-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-12-03vfio-user: simplify vfio_user_process()John Levon1-7/+4
It can figure out if it's a reply by itself, rather than passing that information in. Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-2-john.levon@nutanix.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-11-25hw/aspeed/{xdma, rtc, sdhci}: Fix endianness to DEVICE_LITTLE_ENDIANCédric Le Goater3-3/+3
When the XDMA, RTC and SDHCI device models of the Aspeed SoCs were first introduced, their MMIO regions inherited of a DEVICE_NATIVE_ENDIAN endianness. It should be DEVICE_LITTLE_ENDIAN. Fix that. Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251125142631.676689-1-clg@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/core/machine: Provide a description for aux-ram-share propertyPeter Xu1-0/+2
It was forgotten when being introduced in commit 91792807d1 ("machine: aux-ram-share option"). Cc: qemu-stable@nongnu.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-ID: <20251124191408.783473-1-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/virtio: Use error_setg_file_open() for a better error messageMarkus Armbruster1-2/+1
The error message changes from vhost-vsock: failed to open vhost device: REASON to Could not open '/dev/vhost-vsock': REASON I think the exact file name is more useful to know than the file's purpose. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251121121438.1249498-8-armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/scsi: Use error_setg_file_open() for a better error messageMarkus Armbruster1-2/+1
The error message changes from vhost-scsi: open vhost char device failed: REASON to Could not open '/dev/vhost-scsi': REASON I think the exact file name is more useful to know than the file's purpose. We could put back the "vhost-scsi: " prefix with error_prepend(). Not worth the bother. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251121121438.1249498-7-armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/usb: Convert to qemu_create() for a better error messageMarkus Armbruster1-3/+2
The error message changes from open FILENAME failed to Could not create 'FILENAME': REASON where REASON is the value of strerror(errno). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251121121438.1249498-3-armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/pci: Make msix_init take a uint32_t for nentriesPeter Maydell1-2/+8
msix_init() and msix_init_exclusive_bar() take an "unsigned short" argument for the number of MSI-X vectors to try to use. This is big enough for the maximum permitted number of vectors, which is 2048. Unfortunately, we have several devices (most notably virtio) which allow the user to specify the desired number of vectors, and which use uint32_t properties for this. If the user sets the property to a value that is too big for a uint16_t, the value will be truncated when it is passed to msix_init(), and msix_init() may then return success if the truncated value is a valid one. The resulting mismatch between the number of vectors the msix code thinks the device has and the number of vectors the device itself thinks it has can cause assertions, such as the one in issue 2631, where "-device virtio-mouse-pci,vectors=19923041" is interpreted by msix as "97 vectors" and by the virtio-pci layer as "19923041 vectors"; a guest attempt to access vector 97 thus passes the virtio-pci bounds checking and hits an essertion in msix_vector_use(). Avoid this by making msix_init() and its wrapper function msix_init_exclusive_bar() take the number of vectors as a uint32_t. The erroneous command line will now produce the warning qemu-system-i386: -device virtio-mouse-pci,vectors=19923041: warning: unable to init msix vectors to 19923041 and proceed without crashing. (The virtio device warns and falls back to not using MSIX, rather than complaining that the option is not a valid value this is the same as the existing behaviour for values that are beyond the MSI-X maximum possible value but fit into a 16-bit integer, like 2049.) To ensure this doesn't result in potential overflows in calculation of the BAR size in msix_init_exclusive_bar(), we duplicate the nentries error-check from msix_init() at the top of msix_init_exclusive_bar(), so we know nentries is sane before we start using it. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2631 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251107131044.1321637-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-25hw/nvme: Validate PMR memory sizePhilippe Mathieu-Daudé1-2/+11
Per the PCI spec 3.0, in section 6.2.5.1, "Address Maps": A 32-bit register can be implemented to support a single memory size that is a power of 2 from 16 bytes to 2 GB. Add a check in nvme_init_pmr(), returning an error if the PMR region size is too small; and update the QTest. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2025-11-25hw/nvme: fix up extended protection information formatKeith Busch1-5/+12
Set the protection information format (pif) only in the formats that can support the larger guard types, and update the current in-use format information when the user changes it. Signed-off-by: Keith Busch <kbusch@kernel.org> [k.jensen: fix missing braces and wrong indentation] Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2025-11-25hw/nvme: fix namespace atomic parameter setupKlaus Jensen3-143/+182
Coverity complains about a possible copy-paste error in the verification of the namespace atomic parameters (CID 1642811). While the check is correct, the code (and the intention) is unclear. Fix this by reworking how the parameters are verified. Peter also identified that the realize function was not correctly erroring out if parameters were misconfigured, so fix that too. Lastly, change the error messages to be more describing. Coverity: CID 1642811 Fixes: bce51b83709b ("hw/nvme: add atomic boundary support") Fixes: 3b41acc96299 ("hw/nvme: enable ns atomic writes") Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2025-11-24Merge tag 'pull-target-arm-20251124' of https://gitlab.com/pm215/qemu into ↵Richard Henderson3-2/+20
staging target-arm queue: * hw/display/exynos4210_fimd: Account for zero length in fimd_update_memory_section() * hw/arm/armv7m: Disable reentrancy guard for v7m_sysreg_ns_ops MRs * hw/display/exynos4210_fimd: Remove duplicated definition * hw/arm/Kconfig: Exclude imx8mp-evk machine from KVM-only build # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmkka80ZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3hVpD/48w6peqEy8HmLtmrswBdVt # TIYAkcz3oGNDnpYqB0UsjEVvmtAQZtGLS0XaOSVlB3l8NPiGe5GFwJJmt8TYBUpB # rl76Cbmnx9lHyJshuoHb7CdtY2Q2gWxQPaeqD+cFvWTa/HNzeMO8joS9EkNApubP # B7SQpcZuMgv4mgBTM3ly2/9mmFkKyY+/gkvtOmTMS/wGjrhpIs8DWIgLZ5/odmI5 # +c15aNOsfsnZ7KEsawRyYpn1pV2YeoYWYbQqQGOVLLfF7y/mLSfkI35SoXHI79zu # nU0f/8NKhFswtx+SoAuQtHmnGLpgc5gRL21hwHZxiLkLQif1HgfCT3YNM2V/03ll # +n5lOZzvNY4TLaoc5R9a2B+DRpp7ihrDnpW+tUV5LIhpDT4eqRto6+ATqlJ0Hfkw # konwiahSAuHMMpnmfKbDvieVQasOZZBI0bpdwj3/yzXKh91/cYhAE4RySC1qLWe+ # dHeroqdyWKxbxetQz14kwJVWHDrvZSiSVpc1uVHWYBnrP310kMXlkgGt7MA2qiw5 # Dm01Dz/Upc+FpLGUqwHhZPWf2sJLdQVRqGwEevRkJl80AFpCR10JbSqwN4Fpz2gg # YlkHmFhJfNM7FYoD+c6y4USwxiv0mMmtkIMuR2csmY5F5oH18H6zJ0lYikz5I0eo # MVcNV1lPilWh7lKAKlLlGQ== # =+CbZ # -----END PGP SIGNATURE----- # gpg: Signature made Mon 24 Nov 2025 06:29:33 AM PST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20251124' of https://gitlab.com/pm215/qemu: hw/display/exynos4210_fimd: Account for zero length in fimd_update_memory_section() hw/arm/armv7m: Disable reentrancy guard for v7m_sysreg_ns_ops MRs hw/display/exynos4210_fimd: Remove duplicated definition hw/arm/Kconfig: Exclude imx8mp-evk machine from KVM-only build Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-11-24hw/display/exynos4210_fimd: Account for zero length in ↵Peter Maydell1-0/+7
fimd_update_memory_section() In fimd_update_memory_section() we attempt ot find and map part of the RAM MR which backs the framebuffer, based on guest-configurable size and start address. If the guest configures framebuffer settings which result in a zero-sized framebuffer, we hit an assertion(), because memory_region_find() will return a NULL mem_section.mr. Explicitly check for the zero-size case and treat this as a guest error. Because we now have a code path which can reach error_return without calling memory_region_find to set w->mem_section, we must NULL out w->mem_section.mr after the unref of the old MR, so that error_return does not incorrectly double-unref the old MR. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1407 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251107143913.1341358-1-peter.maydell@linaro.org
2025-11-24hw/arm/armv7m: Disable reentrancy guard for v7m_sysreg_ns_ops MRsPeter Maydell1-0/+12
For M-profile cores which support TrustZone, there are some memory areas which are "NS aliases" -- a Secure access to these addresses really performs an NS access to a different part of the device. We implement these using MemoryRegionOps read and write functions which pass the access on with adjusted attributes using memory_region_dispatch_read() and memory_region_dispatch_write(). Since the MR we are dispatching to is owned by the same device that owns the NS-alias MR (the TYPE_ARMV7M container object), this trips the reentrancy-guard that is applied by access_with_adjusted_size(). Mark the NS alias MemoryRegions as disable_reentrancy_guard; this is safe because v7m_sysreg_ns_read() and v7m_sysreg_ns_write() do not touch any of the device's state. (Any further reentrancy attempts by the underlying MR will still be caught.) Without this fix, an attempt to read from an address like 0xe002e010, which is a register in the NS systick alias, will fail and provoke qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: v7m_systick at addr: 0x0 We didn't notice this earlier because almost all code accesses the registers and systick via the non-alias addresses; the NS aliases are only need for the rarer case of Secure code that needs to manage the NS timer or system state on behalf of NS code. Note that although the v7m_systick_ops read and write functions also call memory_region_dispatch_{read,write}, this MR does not need to have the reentrancy-guard disabled because the underlying MR that it forwards to is owned by a different device (the TYPE_SYSTICK timer device). Reported via a stackoverflow question: https://stackoverflow.com/questions/79808107/what-this-error-is-even-about-qemu-system-arm-warning-blocked-re-entrant-io Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251114155304.2662414-1-peter.maydell@linaro.org
2025-11-24hw/display/exynos4210_fimd: Remove duplicated definitionPhilippe Mathieu-Daudé1-1/+0
FIMD_VIDWADD0_END is defined twice, keep only one. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251121093509.25088-1-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-11-24hw/arm/Kconfig: Exclude imx8mp-evk machine from KVM-only buildBernhard Beschow1-1/+1
Fixes make check failures on an aarch64 host when QEMU is configured using '--enable-kvm --disable-tcg': qemu-system-aarch64: unknown type 'arm-gicv3' Reported-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-id: 20251119203759.5138-1-shentey@gmail.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-11-24hw/pci-host/aspeed_pcie: Update ASPEED PCIe Root Port capabilities and ↵Jamin Lin1-1/+39
enable MSI to support hotplug This patch updates the ASPEED PCIe Root Port capability layout and interrupt handling to match the hardware-defined capability structure as documented in the PCI Express Controller (PCIE) chapter of the ASPEED SoC datasheet. The following capability offsets and fields are now aligned with the actual hardware implementation (validated using EVB config-space dumps via 'lspci -s <bdf> -vvv'): - Added MSI capability at offset 0x50 and enabled 1-vector MSI support - Added PCI Express Capability structure at offset 0x80 - Added Secondary Subsystem Vendor ID (SSVID) at offset 0xC0 - Added AER capability at offset 0x100 - Implemented aer_vector() callback and MSI init/uninit hooks - Updated Root Port SSID to 0x1150 to reflect the platform default Enabling MSI is required for proper PCIe Hotplug event signaling. This change improves correctness and ensures QEMU Root Port behavior matches the behavior of ASPEED hardware and downstream kernel expectations. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Fixes: 2af56518fa91 ("hw/pci-host/aspeed: Add AST2600 PCIe Root Port and make address configurable") Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Nabih Estefan <nabihestefan@google.com> Tested-by: Nabih Estefan <nabihestefan@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/qemu-devel/20251121050108.3407445-2-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-11-24hw/arm/aspeed: Fix missing SPI IRQ connection causing DMA interrupt failureJamin Lin3-0/+6
It did not connect SPI IRQ to the Interrupt Controller, so even the SPI model raised the IRQ, the interrupt was not received. The CPU therefore did not trigger an interrupt via the controller, and the firmware never received the interrupt. Fixes: 356b230ed13889e09d087a96498887de695df17e ("aspeed/soc: Add AST1030 support") Fixes: f25c0ae1079dc0b9de02676eb3e3949a09df9f41 ("aspeed/soc: Add AST2600 support") Fixes: 5dd883ab0635c9f715c77cc32622e458a0724581 ("aspeed/soc: Add AST2700 support") Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20251106084925.1253704-2-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-11-24hw/arm/ast27x0: Fix typo in LTPI addressNabih Estefan1-1/+1
The address for LTPI has one more 0 that it should, bug introduced in commit 91064bea6b2d747a981cb3bd2904e56f443e6c67. Signed-off-by: Nabih Estefan <nabihestefan@google.com> Fixes: 91064bea6b2d ("aspeed: ast27x0: Map unimplemented devices in SoC memory") Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20251104233742.2147367-1-nabihestefan@google.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-11-23Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into stagingRichard Henderson2-2/+2
trivial patches for 2025-11-21 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmkgYNYACgkQgqpKJDse # lHgZIA/+MMazD/z4+niWJinTb/NXq5Q5AbE9x1bivYT8eVdyYrklAn5vqA1tQUHg # nqAHvMEhhl2JtDI/OAABMcMZGay/anqBpuJ17g0CV3nlFQAoYQDI2QZxtBAPXC8K # n8ZtaWrdeASrVPfxohPn5hJvj5j2m0468QRSa/MKad5iBt3F3JuZn8m20X9YkzkI # FHGnRzBYg+6s8p312imEmcPqxId6n4xxJY/i8PnXY+dce//zZqX2UPmjf8aRxDgY # 9eTzio6526w4raIzv/FXUXlnYn/ihRYRWxY/bI0t+7AJ1mY+F5SbFeg0pTr5koEg # 3UQF/U0yILCIWoyoj8qiRmq62DxKCuvC16RdpJ91x3q3hQKmLn+0rpJlTcBHEGkw # T28XEniTrYJKD3LbvZE9dnYcskyPSqpskKixdB94wupWA9XZ/BW6Ivq6ni/Jsozz # wTsdWfyhtI9xd4TKeR2Ondz9xlTjhOTk7OoPgVa+IKESSLZYy4FlFsFV9Bb03I9b # gaB5C7FDzJMa4JT4Wrc95cTtobno7VD6+Qsg78/piWomBPXSWi9QM0Uap2SdA3Ac # s+ZjIrO02jsUdA68MSaxQjPDzdHvuAbvqDXY0+ACFutRZn9Yb7PTbr3m0JwXa8pa # E9nBy850A4XynnU+1wuuPLxJStsKv/182C8x8Mt7hP4HfZ5w0fc= # =1PPo # -----END PGP SIGNATURE----- # gpg: Signature made Fri 21 Nov 2025 04:53:42 AM PST # gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478 # gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown] # gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown] # gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [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: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E # Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478 * tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu: Fix the typo of vfio-pci device's enable-migration option qmp: Fix a typo for a USO feature qga: use access(2) to check for command existance instead of questionable stat(2) Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-11-21Fix the typo of vfio-pci device's enable-migration optionYanghang Liu1-1/+1
Signed-off-by: Yanghang Liu <yanghliu@redhat.com> Reported-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2025-11-21qmp: Fix a typo for a USO featureJack Wang1-1/+1
There is a copy & paste error, USO6 should be there. Fixes: 58f81689789f ("qmp: update virtio feature maps, vhost-user-gpio introspection") Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2025-11-21hw/s390x: Fix a possible crash with passed-through virtio devicesThomas Huth1-0/+14
Consider the following nested setup: An L1 host uses some virtio device (e.g. virtio-keyboard) for the L2 guest, and this L2 guest passes this device through to the L3 guest. Since the L3 guest sees a virtio device, it might send virtio notifications to the QEMU in L2 for that device. But since the QEMU in L2 defined this device as vfio-ccw, the function handle_virtio_ccw_notify() cannot handle this and crashes: It calls virtio_ccw_get_vdev() that casts sch->driver_data into a VirtioCcwDevice, but since "sch" belongs to a vfio-ccw device, that driver_data rather points to a CcwDevice instead. So as soon as QEMU tries to use some VirtioCcwDevice specific data from that device, we've lost. We must not take virtio notifications for such devices. Thus fix the issue by adding a check to the handle_virtio_ccw_notify() handler to refuse all devices that are not our own virtio devices. Like in the other branches that detect wrong settings, we return -EINVAL from the function, which will later be placed in GPR2 to inform the guest about the error. Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Tested-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20251118174047.73103-1-thuth@redhat.com>
2025-11-18ebpf: Make ebpf_rss_load() return value consistent with @errpMarkus Armbruster1-3/+1
ebpf_rss_load() returns false for failure without setting an Error when its @ctx argument already has an eBPF program loaded. This is wrong. Fortunately, it is only called @ctx has a program. Replace the incorrect error check by an assertion. The return value is now obviously reliable. Change the caller to use it, because it's more concise. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251118154718.3969982-4-armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-18hw/sd/sdcard: Avoid confusing address calculation in rpmb_calc_hmacJan Kiszka1-1/+6
From the source frame, we initially need to copy out all fields after data, thus starting from nonce on. Avoid expressing this indirectly by pointing to the end of the data field - which also raised the attention of Coverity (out-of-bound read /wrt data). Resolves: CID 1642869 Reported-by: GuoHan Zhao <zhaoguohan@kylinos.cn> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <4f7e1952-ecbd-4484-b128-9d02de3a7935@siemens.com> [PMD: Add comment before the memcpy() call] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-18hw/arm: Re-enable xenpvh machine in qemu-system-arm/aarch64 binariesPhilippe Mathieu-Daudé1-0/+2
While registering the ARM/Aarch64 machine interfaces in commit 38c5ab40031 ("hw/arm: Filter machine types for qemu-system-arm/aarch64 binaries"), we missed the XenPV machine. Correct that. Reported-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-Id: <20251117091253.56009-1-philmd@linaro.org>
2025-11-18hw/dma/zynq-devcfg: Fix register memoryYannick Voßen1-1/+1
Registers are always 32 bit aligned. R_MAX is not the maximum register address, it is the maximum register number. The memory size can be determined by 4 * R_MAX. Currently every register with an offset bigger than 0x40 will be ignored, because the memory size is set wrong. This effects the MCTRL register and makes it useless. This commit restores the correct behaviour. Cc: qemu-stable@nongnu.org Fixes: 034c2e69023 ("dma: Add Xilinx Zynq devcfg device model") Signed-off-by: YannickV <Y.Vossen@beckhoff.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251111102836.212535-9-corvin.koehne@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-18hw/sd: Fix ACMD41 state machine in SPI modeBin Meng1-11/+12
In SPI mode, the ACMD41 argument only defines bit 30 (HCS); all other bits are reserved. The current implementation incorrectly checks the voltage window bits even in SPI mode, preventing the state machine from transitioning to the READY state. As a result, the U-Boot mmc-spi driver falls into an endless CMD55/ACMD41 loop. Fixes: 3241a61a ("hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945 Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251110110507.1641042-3-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-18hw/sd: Fix incorrect idle state reporting in R1 response for SPI modeBin Meng1-2/+1
Since commit b66f73a0 ("hw/sd: Add SDHC support for SD card SPI-mode"), the CARD_POWER_UP bit in the OCR register has been set after reset. Therefore, checking this bit against zero in sd_response_r1_make() to determine the card’s idle state is incorrect in SPI mode. As a result, QEMU makes the U-Boot mmc-spi driver believe the card never leaves the reset state. Fixes: 1585ab9f ("hw/sd/sdcard: Fill SPI response bits in card code") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945 Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251110110507.1641042-2-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-18hw/intc/ioapic: Fix ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typoCédric Le Goater1-2/+2
Commit 638ac1c78457 introduced a regression in interrupt remapping when running a VM configured with an intel-iommu device and an assigned PCI VF. During boot, Linux reports repeated messages : [ 15.416794] __common_interrupt: 2.37 No irq handler for vector [ 15.417266] __common_interrupt: 2.37 No irq handler for vector [ 15.417733] __common_interrupt: 2.37 No irq handler for vector [ 15.418202] __common_interrupt: 2.37 No irq handler for vector [ 15.418670] __common_interrupt: 2.37 No irq handler for vector and may eventually hang. The issue is caused by the incorrect use of the macro ACCEL_KERNEL_GSI_IRQFD_POSSIBLE, which should instead be ACCEL_GSI_IRQFD_POSSIBLE. Fixes: 638ac1c78457 ("hw/intc: Generalize APIC helper names from kvm_* to accel_*") Cc: Magnus Kulke <magnuskulke@linux.microsoft.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20251106105148.737093-1-clg@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-14Merge tag 'pull-target-arm-20251114' of https://gitlab.com/pm215/qemu into ↵Richard Henderson13-21/+100
staging target-arm queue: * MAINTAINERS file update for whpx * target/arm: Fix accidental write to TCG constant * target/arm/cpu64: remove duplicate include * hw/display/xlnx_dp: don't abort() on guest errors * cxl, vfio, tests: clean up includes * hw/misc/npcm_clk: Don't divide by zero when calculating frequency * hw/audio/lm4549: Don't try to open a zero-frequency audio voice # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmkXSF0ZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3iLKEACahSPxoRe4+TOgr3F7mJvq # CDFOOUQSXbBC4WTviyJAh1+MYFhtWrOxUB1EzLb9iw1+sbBcT6/K1CBEFiQ65dpn # kjtIaJDidz4x52vNc1nz1B9jzRdme4xQ0kg5NeY9PqCGO4nC0iWqzzbBoA1XYHsR # RXfXr9JNXKqN3cm+x/ZX/o++rz3eG8ba0DxJUIO+OR9rAv3n0No+oTOeAJ4SbDu4 # lcP+MHFA/V//Q4O9QSeZv1tD+brXerpNcMQlsRrffkmT8bvJMPozyvcijtEZQz3+ # 9s8GUeL0b7/GgpdIqWyEAl2sreMtqmWh1GGpCZziFTiEmNWWI9M6fHINyZ2NVnPD # T5UFOA9JbSG1ybxQHHf4Vj5tUjwWAAnVwRP1wXAb3p35fBYl0Y3JFDX+0HpL9tM/ # vB1BHA+PGRV51vDy7VoUpbbZkpa1/WJCqTm9s1BxzZ2BFu0tpQ2Rqg/V+y004NQY # Xx1t7ilm18LyQrZpHYqmw3OJ/EVPtATBN2jomK2Z8ZWExLsDQ/Qd8k3cHg6OcN4N # /ORpbqy29dOL5mQTEuBW8L0tLEN9tBqfadlqvlsbI9S0eDlZdyvPT9utV0aSCfe2 # km/rSjD2IJEmtJA1kcYgq3ipNsPu5eGFfw2OqGe+vowLaU42ki3uteaOqLgN81AX # sB5cO49w7AtAmaocraAzPA== # =+I+o # -----END PGP SIGNATURE----- # gpg: Signature made Fri 14 Nov 2025 04:18:53 PM CET # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20251114' of https://gitlab.com/pm215/qemu: hw/audio/lm4549: Don't try to open a zero-frequency audio voice hw/misc/npcm_clk: Don't divide by zero when calculating frequency tests: Clean up includes vfio: Clean up includes cxl: Clean up includes hw/display/xlnx_dp: Don't abort for unsupported graphics formats hw/display/xlnx_dp.c: Don't abort on AUX FIFO overrun/underrun target/arm/cpu64: remove duplicate include target/arm: Fix accidental write to TCG constant MAINTAINERS: update maintainers for WHPX Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-11-14hw/audio/lm4549: Don't try to open a zero-frequency audio voicePeter Maydell1-1/+16
If the guest incorrectly programs the lm4549 audio chip with a zero frequency, we will pass this to AUD_open_out(), which will complain: A bug was just triggered in AUD_open_out Save all your work and restart without audio I am sorry Context: audio: frequency=0 nchannels=2 fmt=S16 endianness=little The datasheet doesn't say what we should do here, only that the valid range for the freqency is 4000 to 48000 Hz; we choose to log the guest error and ignore an attempt to change the DAC rate to something outside the valid range. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/410 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251107154116.1396769-1-peter.maydell@linaro.org
2025-11-14hw/misc/npcm_clk: Don't divide by zero when calculating frequencyPeter Maydell1-2/+3
If the guest misprograms the PLL registers to request a zero divisor, we currently fall over with a division by zero: ../../hw/misc/npcm_clk.c:221:14: runtime error: division by zero SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../hw/misc/npcm_clk.c:221:14 Thread 1 "qemu-system-aar" received signal SIGFPE, Arithmetic exception. 0x00005555584d8f6d in npcm7xx_clk_update_pll (opaque=0x7fffed159a20) at ../../hw/misc/npcm_clk.c:221 221 freq /= PLLCON_INDV(con) * PLLCON_OTDV1(con) * PLLCON_OTDV2(con); Avoid this by treating this invalid setting like a stopped clock (setting freq to 0). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/549 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251107150137.1353532-1-peter.maydell@linaro.org
2025-11-14vfio: Clean up includesPeter Maydell8-8/+4
This commit was created with scripts/clean-includes: ./scripts/clean-includes --git vfio hw/vfio hw/vfio-user All .c should include qemu/osdep.h first. The script performs three related cleanups: * Ensure .c files include qemu/osdep.h first. * Including it in a .h is redundant, since the .c already includes it. Drop such inclusions. * Likewise, including headers qemu/osdep.h includes is redundant. Drop these, too. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251104160943.751997-9-peter.maydell@linaro.org
2025-11-14cxl: Clean up includesPeter Maydell2-2/+2
This commit was created with scripts/clean-includes: ./scripts/clean-includes --git cxl hw/cxl hw/mem All .c should include qemu/osdep.h first. The script performs three related cleanups: * Ensure .c files include qemu/osdep.h first. * Including it in a .h is redundant, since the .c already includes it. Drop such inclusions. * Likewise, including headers qemu/osdep.h includes is redundant. Drop these, too. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Message-id: 20251104160943.751997-8-peter.maydell@linaro.org
2025-11-14hw/display/xlnx_dp: Don't abort for unsupported graphics formatsPeter Maydell1-6/+49
If the guest writes an invalid or unsupported value to the AV_BUF_FORMAT register, currently we abort(). Instead, log this as either a guest error or an unimplemented error and continue. The existing code treats DP_NL_VID_CB_Y0_CR_Y1 as x8b8g8r8 via a "case 0" that does not use the enum constant name for some reason; we leave that alone beyond adding a comment about the weird code. Documentation of this register seems to be at: https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/AV_BUF_FORMAT-DISPLAY_PORT-Register Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1415 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20251106145209.1083998-3-peter.maydell@linaro.org
2025-11-14hw/display/xlnx_dp.c: Don't abort on AUX FIFO overrun/underrunPeter Maydell1-2/+26
The documentation of the Xilinx DisplayPort subsystem at https://www.xilinx.com/support/documents/ip_documentation/v_dp_txss1/v3_1/pg299-v-dp-txss1.pdf doesn't say what happens if a guest tries to issue an AUX write command with a length greater than the amount of data in the AUX write FIFO, or tries to write more data to the write FIFO than it can hold, or issues multiple commands that put data into the AUX read FIFO without reading it such that it overflows. Currently QEMU will abort() in these guest-error situations, either in xlnx_dp.c itself or in the fifo8 code. Make these cases all be logged as guest errors instead. We choose to ignore the new data on overflow, and return 0 on underflow. This is in line with how we handled the "read from empty RX FIFO" case in commit a09ef5040477. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1418 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1419 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1424 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-id: 20251106145209.1083998-2-peter.maydell@linaro.org
2025-11-14hw/net/e1000e_core: Adjust e1000e_write_payload_frag_to_rx_buffers() assertPeter Maydell1-6/+7
An assertion in e1000e_write_payload_frag_to_rx_buffers() attempts to guard against the calling code accidentally trying to write too much data to a single RX descriptor, such that the E1000EBAState::cur_idx indexes off the end of the EB1000BAState::written[] array. Unfortunately it is overzealous: it asserts that cur_idx is in range after it has been incremented. This will fire incorrectly for the case where the guest configures four buffers and exactly enough bytes are written to fill all four of them. The only places where we use cur_idx and index in to the written[] array are the functions e1000e_write_hdr_frag_to_rx_buffers() and e1000e_write_payload_frag_to_rx_buffers(), so we can rewrite this to assert before doing the array dereference, rather than asserting after updating cur_idx. Cc: qemu-stable@nongnu.org Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-11-14hw/net/e1000e_core: Correct rx oversize packet checksPeter Maydell1-14/+47
In e1000e_write_packet_to_guest() we attempt to ensure that we don't write more of a packet to a descriptor than will fit in the guest configured receive buffers. However, this code does not allow for the "packet split" feature. When packet splitting is enabled, the first of up to 4 buffers in the descriptor is used for the packet header only, with the payload going into buffers 2, 3 and 4. Our length check only checks against the total sizes of all 4 buffers, which meant that if an incoming packet was large enough to fit in (1 + 2 + 3 + 4) but not into (2 + 3 + 4) and packet splitting was enabled, we would run into the assertion in e1000e_write_hdr_frag_to_rx_buffers() that we had enough buffers for the data: qemu-system-i386: ../../hw/net/e1000e_core.c:1418: void e1000e_write_payload_frag_to_rx_buffers(E1000ECore *, hwaddr *, E1000EBAState *, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS' failed. A malicious guest could provoke this assertion by configuring the device into loopback mode, and then sending itself a suitably sized packet into a suitably arrange rx descriptor. The code also fails to deal with the possibility that the descriptor buffers are sized such that the trailing checksum word does not fit into the last descriptor which has actual data, which might also trigger this assertion. Rework the length handling to use two variables: * desc_size is the total amount of data DMA'd to the guest for the descriptor being processed in this iteration of the loop * rx_desc_buf_size is the total amount of space left in it As we copy data to the guest (packet header, payload, checksum), update these two variables. (Previously we attempted to calculate desc_size once at the top of the loop, but this is too difficult to do correctly.) Then we can use the variables to ensure that we clamp the amount of copied payload data to the remaining space in the descriptor's buffers, even if we've used one of the buffers up in the packet-split code, and we can tell whether we have enough space for the full checksum word in this descriptor or whether we're going to need to split that to the following descriptor. I have included comments that hopefully help to make the loop logic a little clearer. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/537 Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-11-14hw/net/e1000e_core: Don't advance desc_offset for NULL buffer RX descriptorsPeter Maydell1-11/+10
In e1000e_write_packet_to_guest() we don't write data for RX descriptors where the buffer address is NULL (as required by the i82574 datasheet section 7.1.7.2). However, when we do this we still update desc_offset by the amount of data we would have written to the RX descriptor if it had a valid buffer pointer, resulting in our dropping that data entirely. The data sheet is not 100% clear on the subject, but this seems unlikely to be the correct behaviour. Rearrange the null-descriptor logic so that we don't treat these do-nothing descriptors as if we'd really written the data. This both fixes a bug and also is a prerequisite to cleaning up the size calculation logic in the next patch. (Cc to stable largely because it will be needed for the next patch, which fixes a more serious bug.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Jason Wang <jasowang@redhat.com>
2025-11-10Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson11-117/+354
into staging virtio,pci,pc: fixes for 10.2 small fixes all over the place. UDP tunnel and TSEG tweaks are kind of borderline, but I feel not making the change now will just add to compatibility headaches down the road. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmkQplIPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRpFDsIAMlScYTW0fugUaP4B/a8xjgRFwBSk2CoU7aE # l0k5ihyadecpnMLswkvoLfH9jl5Mu3MOZ6bpfcIHOWXMusGyiYcds6wupb8qcATP # Ud4ZjybuNrpoGUul1ECkNTE3xvUtSBOVu8z9ac4ojP+w0LVDiuWyg1bl5QiRuzEg # K87OjbdTIgCKKJi5QRw/dMJfoOofay98g0kbcuhkBiudvu3FtOpJW0g/aiY1m2sY # MXYeBZjGbYGkAOXLKRcSr3nYtZbY4sg/onJ3Xb0HPbUZfRMTm7KKApwhH9jsHmlO # VgaRGcF+dNDC7XIsaZt6k/YTsWCApYvuCcEQbjR1rW1d4ZmZU/Y= # =ocWR # -----END PGP SIGNATURE----- # gpg: Signature made Sun 09 Nov 2025 03:33:54 PM CET # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [unknown] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: vhost-user.rst: clarify when FDs can be sent q35: increase default tseg size virtio-net: Advertise UDP tunnel GSO support by default tests/qtest/bios-tables-test: Update DSDT blobs after GPEX _DSM change hw/pci-host/gpex-acpi: Fix _DSM function 0 support return value tests/qtest/bios-tables-test: Prepare for _DSM change in the DSDT table vhost-user: make vhost_set_vring_file() synchronous intel_iommu: Fix DMA failure when guest switches IOMMU domain intel_iommu: Reset pasid cache when system level reset intel_iommu: Handle PASID cache invalidation vhost-user: fix shared object lookup handler logic amd_iommu: Support 64-bit address for IOTLB lookup amd_iommu: Fix handling of devices on buses != 0 MAINTAINERS: Update entry for AMD-Vi Emulation Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-11-10Merge tag 'pull-ppc-for-10.2-d5-20251110' of https://gitlab.com/harshpb/qemu ↵Richard Henderson1-1/+2
into staging PPC Patches for 10.2 Hard Freeze * Pegasos fixes for mem leak and dtb blob updates # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEa4EM1tK+EPOIPSFCRUTplPnWj7sFAmkRm/YACgkQRUTplPnW # j7tTWA/+PTQfODH0dRpuApQys23okruXRJ0C26e+1Bb/H7IeSerfZ33GgpgW8ldi # R6amhrJ4GYXFkjK34iFV+daXhtKEA/44fBykr1SCwDixiD7qGGq7a0yOEDERurEq # eDn4of82O2C2l1jUY+hx0jXgWlEQLAeLH1bVwikJL75jbV7Ob7wt3W3bC7M6iup9 # jaZP6RwcXW9JqFeavS5r3DCbdPf+U/jafmxIP+qpZVS92jwxcOZbmsXgZVPW92xe # Cwc8AY3FwUIdUfPGKj2uyuJNtLWuev0+o1roZ8mmuiSFoMGQuw+X5bmLt0qBvVyK # EPc0dxsliyUhPso4vq9SCI9hBid0NQlsqpGpRWpEuP0z8vc4aF41P++VBC4DQ8ls # Ffc2dz3ncUhII8V+N7jGykWG2ZKOqxgndlq7V/8k2f96kbDWEXNYJomnJd5NN6NK # uKlKQN9pu2Btp2Lo9bLNVQT3jclByBmNtSyzqQhbLT/JbhTorhs6mYilTM8Wv7da # 1Dn+PesmxTMtO7wgjy1qu6Ms55zTweKvpW0sNDMOMGOvQ1ssff/3WT8nrk1jXXHw # UeEidzTZtr375LkCJ7DQnChztr9YjiQLPPAEkpUMz1sV32fGRrOr4kR3zGbjAiBY # ARZLAErqHBMYO0NYi/+MR266cjZ841d+ImrP329BZqBvGfGBbpE= # =iAZh # -----END PGP SIGNATURE----- # gpg: Signature made Mon 10 Nov 2025 09:01:58 AM CET # gpg: using RSA key 6B810CD6D2BE10F3883D21424544E994F9D68FBB # gpg: Good signature from "Harsh Prateek Bora <harsh.prateek.bora@gmail.com>" [undefined] # gpg: aka "Harsh Prateek Bora <harshpb@linux.ibm.com>" [undefined] # 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: 6B81 0CD6 D2BE 10F3 883D 2142 4544 E994 F9D6 8FBB * tag 'pull-ppc-for-10.2-d5-20251110' of https://gitlab.com/harshpb/qemu: pc-bios/dtb/pegasos*.dtb: Fix compiled dtb blobs hw/ppc/pegasos: Fix memory leak Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-11-09ncr710: Use address space of device instead of global address spaceSoumyajyotii Ssarkar1-3/+3
Signed-off-by: Soumyajyotii Ssarkar <soumyajyotisarkar23@gmail.com> Reviewed-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
generated by cgit v1.1 at 2025-12-26 07:55:24 +0000