aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-08-03roms/vbootrom: update to 7b1eb5f7fe6aMichael Tokarev1-0/+0
Changes: 7b1eb5f ast27x0: Fix Makefile to unconditionally set CC to support correct cross-compilation 601d410 ast27x0: Fix missing SCU module reset for SSP and TSP initialization 80768e4 ast27x0: Initialize and enable SSP/TSP using SCU with reserved-memory from DTB f8ab635 ast27x0: Show build date and git version 53294f5 Add initial support for AST27x0 b1c2803 Dynamically detects NPCM8XX UBOOT destination and size. 4f54dfc Automatically search for UBOOT location for NPCM8xx images. The actual bootroms are not updated yet. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Link: https://lore.kernel.org/qemu-devel/2a89ad4c8f5665d07952a4f1749caa6ec0cd3d9c.1753654515.git.mjt@tls.msk.ru [ clg: Update to latest vbootrom ] Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-08-01tests/tcg: Fix run for tests with specific pluginGustavo Romero4-6/+20
Commit 25aaf0cb7f (“tests/tcg: reduce the number of plugin test combinations”) added support for running tests with specific plugins passed via the EXTRA_RUNS variable. However, due to the optimization, the rules generated as a shuffled combination of tests and plugins might not cover the rules required to run the tests with a specific plugin passed via EXTRA_RUNS. This commit fixes it by correctly generating the rules for the tests that require a specific plugin to run, which are now passed via the EXTRA_RUNS_WITH_PLUGIN instead of via the EXTRA_RUNS variable. The fix essentially excludes the tests passed via EXTRA_RUNS_WITH_PLUGIN from the rules created by the shuffled combination of tests and plugins, to avoid running the tests twice, and generates the rules for the test/plugin combinations listed in the EXTRA_RUNS_WITH_PLUGIN variable. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Tested-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-id: 20250801001305.2352554-1-gustavo.romero@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-08-01target/arm: Fix handling of setting SVE registers from gdbVacha Bhavsar1-5/+12
The code to handle setting SVE registers via the gdbstub is broken: * it sets each pair of elements in the zregs[].d[] array in the wrong order for the most common (little endian) case: the least significant 64-bit value comes first * it makes no attempt to handle target_endian() * it does a simple copy out of the (target endian) gdbstub buffer into the (host endan) zregs data structure, which is wrong on big endian hosts Fix all these problems: * use ldq_p() to read from the gdbstub buffer * check target_big_endian() to see if we need to handle the 128-bit values the opposite way around Cc: qemu-stable@nongnu.org Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com> Message-id: 20250722173736.2332529-3-vacha.bhavsar@oss.qualcomm.com [PMM: adjusted commit message, fixed spacing] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-08-01target/arm: Fix big-endian handling of NEON gdb remote debuggingVacha Bhavsar1-2/+16
In the code for allowing the gdbstub to set the value of an AArch64 FP/SIMD register, we weren't accounting for target_big_endian() being true. This meant that for aarch64_be-linux-user we would set the two halves of the FP register the wrong way around. The much more common case of a little-endian guest is not affected; nor are big-endian hosts. Correct the handling of this case. Cc: qemu-stable@nongnu.org Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com> Message-id: 20250722173736.2332529-2-vacha.bhavsar@oss.qualcomm.com [PMM: added comment, expanded commit message, fixed missing space] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-08-01target/arm: Reinstate bogus AArch32 DBGDTRTX register for migration compatPeter Maydell1-0/+29
In commit 655659a74a we fixed some bugs in the encoding of the Debug Communications Channel registers, including that we were incorrectly exposing an AArch32 register at p14, 3, c0, c5, 0. Unfortunately removing a register is a break of forwards migration compatibility for TCG, because we will fail the migration if the source QEMU passes us a cpreg which the destination QEMU does not have. We don't have a mechanism for saying "it's OK to ignore this sysreg in the inbound data", so for the 10.1 release reinstate the incorrect AArch32 register. (We probably have had other cases in the past of breaking migration compatibility like this, but we didn't notice because we didn't test and in any case not that many people care about TCG migration compatibility. KVM migration compat is not affected because for KVM we treat the kernel as the source of truth for what system registers are present.) Fixes: 655659a74a36b ("target/arm: Correct encoding of Debug Communications Channel registers") Reported-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250731134338.250203-1-peter.maydell@linaro.org
2025-08-01hw/display/framebuffer: Add cast to force 64x64 multiplyPeter Maydell1-3/+3
In framebuffer_update_display(), Coverity complains because we multiply two values of type 'int' (which will be done as a 32x32 multiply and so in theory might overflow) and then add the result to a ram_addr_t, which can be 64 bits. 4GB framebuffers are not plausible anyway, but keep Coverity happy by adding casts which force these multiplies to be done as 64x64. Coverity: CID 1487248 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-id: 20250710174312.1313177-1-peter.maydell@linaro.org
2025-08-01hw/intc/arm_gicv3_kvm: Write all 1's to clear enable/activeZenghui Yu1-1/+1
KVM's userspace access interface to the GICD enable and active bits is via set/clear register pairs which implement the hardware's "write 1s to the clear register to clear the 0 bits, and write 1s to the set register to set the 1 bits" semantics. We didn't get this right, because we were writing 0 to the clear register. Writing 0 to GICD_IC{ENABLE,ACTIVE}R architecturally has no effect on interrupt status (all writes are simply ignored by KVM) and doesn't comply with the intention of "first write to the clear-reg to clear all bits". Write all 1's to actually clear the enable/active status. This didn't have any adverse effects on migration because there we start with a clean VM state; it would be guest-visible when doing a system reset, but since Linux always cleans up the register state of the GIC during bootup before it enables it most users won't have run into a problem here. Cc: qemu-stable@nongnu.org Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions") Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Message-id: 20250729161650.43758-3-zenghui.yu@linux.dev Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-08-01hw/intc/arm_gicv3_kvm: Remove writes to ICPENDR registersZenghui Yu1-3/+1
As per the arm-vgic-v3 kernel doc [1]: Accesses to GICD_ICPENDR register region and GICR_ICPENDR0 registers have RAZ/WI semantics, meaning that reads always return 0 and writes are always ignored. The state behind these registers (both 0 and 1 bits) is written by writing to the GICD_ISPENDR and GICR_ISPENDR0 registers, unlike some of the other set/clear register pairs. Remove the useless writes to ICPENDR registers in kvm_arm_gicv3_put(). [1] https://docs.kernel.org/virt/kvm/devices/arm-vgic-v3.html Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Message-id: 20250729161650.43758-2-zenghui.yu@linux.dev Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-08-01Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Stefan Hajnoczi11-64/+140
into staging virtio,pci,pc: bugfixes small fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmiMzgoPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRpAO4H+gKeZbkJFFPHBduwn/LyTTkBpEghy14wEp7G # 6y3knCkWXOVOnFJ/Lw1p6ZLtB6o547Ktin49msY+SKF2X33N1b6I0DmLxixnLVqP # fHMUF+/QssH7QdIMuZNTxr/nwdDzGnj6Rv4xVyrwdZlf+nQPE8GuXWPmAmyGwcXM # 1sEPTjZq30y2eRiQkKsgS7g+COqfPy+O3VeiyQWR1Q/Cb85alegGwUPBy289u3V+ # uHaBC6d73NWxRCHJM4J8CnWpY5LA+y/YgfJXys1NH8pzRLbTpiYt7gfUbfdHbIvF # IpjZraVh+ApbwXhQLmDmsHtGsyIE1zFlcZTq9pR6WUgYGUDQMpY= # =cJxn # -----END PGP SIGNATURE----- # gpg: Signature made Fri 01 Aug 2025 10:24:10 EDT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # 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: net/vdpa: fix potential fd leak in net_init_vhost_vdpa() MAINTAINERS: add net/vhost* files under `vhost` intel_iommu: Allow both Status Write and Interrupt Flag in QI wait tests/acpi: virt: update HEST file with its current data tests/qtest/bios-tables-test: extend to also check HEST table tests/acpi: virt: add an empty HEST file hw/i386/amd_iommu: Fix event log generation hw/i386/amd_iommu: Support MMIO writes to the status register hw/i386/amd_iommu: Fix amdvi_write*() hw/i386/amd_iommu: Move IOAPIC memory region initialization to the end hw/i386/amd_iommu: Remove unused and wrongly set ats_enabled field hw/i386/amd_iommu: Fix MMIO register write tracing pcie_sriov: Fix configuration and state synchronization virtio-net: Fix VLAN filter table reset timing vhost: Do not abort on log-stop error vhost: Do not abort on log-start error virtio: fix off-by-one and invalid access in virtqueue_ordered_fill Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-08-01Merge tag 'pull-loongarch-20250731' of https://github.com/gaosong715/qemu ↵Stefan Hajnoczi2-13/+18
into staging pull-loongarch-2025-0731-for 10.1 # -----BEGIN PGP SIGNATURE----- # # iLMEAAEIAB0WIQTKRzxE1qCcGJoZP81FK5aFKyaCFgUCaIszPgAKCRBFK5aFKyaC # FpqqA/99JIEREUkjaHVVO6Skk89+uYjeIFG6NqY0BwMV1mUT9w+P2Jkcx/pzAWGg # zYrzH9SqjLkmKnjCNlPsuRBD9Ug82CzPOKZ+KBwhqfD6T2YzfjuEvSeq/6kAQmC1 # SWugBYXJGkcDqOPhxkUAS+JEkBj4RqNdPLK2wJxnpJsKc5KG5g== # =wpZU # -----END PGP SIGNATURE----- # gpg: Signature made Thu 31 Jul 2025 05:11:26 EDT # gpg: using RSA key CA473C44D6A09C189A193FCD452B96852B268216 # gpg: Good signature from "Song Gao <gaosong@loongson.cn>" [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: CA47 3C44 D6A0 9C18 9A19 3FCD 452B 9685 2B26 8216 * tag 'pull-loongarch-20250731' of https://github.com/gaosong715/qemu: hw/intc/loongarch_ipi: Fix start fail with smp cpu < smp maxcpus on KVM target/loongarch: Fix valid virtual address checking Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-08-01net/vdpa: fix potential fd leak in net_init_vhost_vdpa()Stefano Garzarella1-3/+2
Coverity reported a file descriptor leak (CID 1490785) that happens if `vhost_vdpa_get_max_queue_pairs()` returns 0, since in that case net_host_vdpa_init(), which should take ownership of the fd, is never called. vhost_vdpa_get_max_queue_pairs() returns 1 if VIRTIO_NET_F_MQ is not negotiated, or a negative error if the ioctl() fails, or the maximum number of queue pairs exposed by the device in the config space in the `max_virtqueue_pairs` field. In the VIRTIO spec we have: The device MUST set max_virtqueue_pairs to between 1 and 0x8000 inclusive, if it offers VIRTIO_NET_F_MQ. So, if `vhost_vdpa_get_max_queue_pairs()` returns 0, it's really an error since the device is violating the VIRTIO spec. Treat also `queue_pairs == 0` as an error, and jump to the `err` label, to return a negative value to the caller in any case. Coverity: CID 1490785 Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20250714101156.30024-1-sgarzare@redhat.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Acked-by: Jason Wang <jasowang@redhat.com>
2025-08-01MAINTAINERS: add net/vhost* files under `vhost`Stefano Garzarella1-0/+1
net/vhost* files should be interesting for vhost maintainers/reviewers. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20250714102626.34431-1-sgarzare@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01intel_iommu: Allow both Status Write and Interrupt Flag in QI waitDavid Woodhouse1-6/+9
FreeBSD does both, and this appears to be perfectly valid. The VT-d spec even talks about the ordering (the status write should be done first, unsurprisingly). We certainly shouldn't assert() and abort QEMU if the guest asks for both. Fixes: ed7b8fbcfb88 ("intel-iommu: add supports for queued invalidation interface") Closes: https://gitlab.com/qemu-project/qemu/-/issues/3028 Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <0122cbabc0adcc3cf878f5fd7834d8f258c7a2f2.camel@infradead.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01tests/acpi: virt: update HEST file with its current dataMauro Carvalho Chehab2-1/+0
Now that HEST table is checked for aarch64, add the current firmware file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <e3527be1610b2ef6b20ca2efa025de91a1f1e0a6.1749741085.git.mchehab+huawei@kernel.org>
2025-08-01tests/qtest/bios-tables-test: extend to also check HEST tableMauro Carvalho Chehab1-1/+1
Currently, aarch64 can generate a HEST table when loaded with -machine ras=on. Add support for it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <9ce77140500ef68cc939d63952c25579f711ea52.1749741085.git.mchehab+huawei@kernel.org>
2025-08-01tests/acpi: virt: add an empty HEST fileMauro Carvalho Chehab2-0/+1
Such file will be used to track HEST table changes. For now, disallow HEST table check until we update it to the current data. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <e25ea751a23c7d8da812233c83ce943efbeaaf91.1749741085.git.mchehab+huawei@kernel.org>
2025-08-01hw/i386/amd_iommu: Fix event log generationSairaj Kodilkar2-9/+36
Current event logging code is broken, because of following issues 1. The code uses '|' instead of '&' to test the bit field, which causes vIOMMU to generate overflow interrupt for every log entry. 2. Code does not update the eventlog tail MMIO register after adding an entry to the buffer, because of which guest cannot process new entries (as head == tail means buffer is empty). 3. Compares eventlog tail (which is byte offset in the buffer) to eventlog length (which is number of maximum entries in the buffer). This causes vIOMMU to generate only fix number of event logs, after which it keeps on generating overflow interrupts, without actually resetting the log buffer. 4. Updates ComWaitInt instead of EventLogInt bitfield in Status register. Guest checks this field to see if there are new event log entries in the buffer. 5. Does not reset event log head and tail pointers when guest writes to eventlog base register. Fix above issues, so that guest can process event log entries. Fixes: d29a09ca68428 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250801060507.3382-7-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01hw/i386/amd_iommu: Support MMIO writes to the status registerSairaj Kodilkar1-0/+3
Support the writes to the status register so that guest can reset the EventOverflow, EventLogInt, ComWaitIntr, etc bits after servicing the respective interrupt. Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250801060507.3382-6-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01hw/i386/amd_iommu: Fix amdvi_write*()Sairaj Kodilkar1-3/+18
amdvi_write*() function do not preserve the older values of W1C bits in the MMIO register. This results in all W1C bits set to 0, when guest tries to reset a single bit by writing 1 to it. Fix this by preserving W1C bits in the old value of the MMIO register. Fixes: d29a09ca68428 ("hw/i386: Introduce AMD IOMMU") Suggested-by: Ethan MILON <ethan.milon@eviden.com> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Message-Id: <20250801060507.3382-5-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01hw/i386/amd_iommu: Move IOAPIC memory region initialization to the endSairaj Kodilkar1-3/+3
Setting up IOAPIC memory region requires mr_sys and mr_ir. Currently these two memory regions are setup after the initializing the IOAPIC memory region, which cause `amdvi_host_dma_iommu()` to use unitialized mr_sys and mr_ir. Move the IOAPIC memory region initialization to the end in order to use the mr_sys and mr_ir regions after they are fully initialized. Fixes: 577c470f4326 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250801060507.3382-4-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01hw/i386/amd_iommu: Remove unused and wrongly set ats_enabled fieldSairaj Kodilkar2-4/+2
The ats_enabled field is set using HTTUNEN, which is wrong. Fix this by removing the field as it is never used. MST: includes a tweak suggested by Philippe Fixes: d29a09ca68428 ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250801060507.3382-3-sarunkod@amd.com> Message-ID: <948a6ac3-ded9-475b-8c45-9d36220b442b@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01hw/i386/amd_iommu: Fix MMIO register write tracingSairaj Kodilkar1-5/+18
Define separate functions to trace MMIO write accesses instead of using `trace_amdvi_mmio_read()` for both read and write. Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20250801060507.3382-2-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01pcie_sriov: Fix configuration and state synchronizationAkihiko Odaki1-19/+23
Fix issues in PCIe SR-IOV configuration register handling that caused inconsistent internal state due to improper write mask handling and incorrect migration behavior. Two main problems were identified: 1. VF Enable bit write mask handling: pcie_sriov_config_write() incorrectly assumed that its val parameter was already masked, causing it to ignore the actual write mask. This led to the VF Enable bit being processed even when masked, resulting in incorrect VF registration/unregistration. It is identified as CVE-2025-54567. 2. Migration state inconsistency: pcie_sriov_pf_post_load() unconditionally called register_vfs() regardless of the VF Enable bit state, creating inconsistent internal state when VFs should not be enabled. Additionally, it failed to properly update the NumVFs write mask based on the current configuration. It is identified as CVE-2025-54566. Root cause analysis revealed that both functions relied on incorrect special-case assumptions instead of properly reading and consuming the actual configuration values. This change introduces a unified consume_config() function that reads actual configuration values and synchronize the internal state without special-case assumptions. The solution only adds register read overhead in non-hot-path code while ensuring correct SR-IOV state management across configuration writes and migration scenarios. Fixes: 5e7dd17e4348 ("pcie_sriov: Remove num_vfs from PCIESriovPF") Fixes: f9efcd47110d ("pcie_sriov: Register VFs after migration") Fixes: CVE-2025-54566 Fixes: CVE-2025-54567 Cc: qemu-stable@nongnu.org Reported-by: Corentin BAYET <corentin.bayet@reversetactics.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Message-Id: <20250727-wmask-v2-1-394910b1c0b6@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01virtio-net: Fix VLAN filter table reset timingAkihiko Odaki1-3/+4
Problem ------- The expected initial state of the table depends on feature negotiation: With VIRTIO_NET_F_CTRL_VLAN: The table must be empty in accordance with the specification. Without VIRTIO_NET_F_CTRL_VLAN: The table must be filled to permit all VLAN traffic. Prior to commit 06b636a1e2ad ("virtio-net: do not reset vlan filtering at set_features"), virtio_net_set_features() always reset the VLAN table. That commit changed the behavior to skip table reset when VIRTIO_NET_F_CTRL_VLAN was negotiated, assuming the table would be properly cleared during device reset and remain stable. However, this assumption breaks when a driver renegotiates features: 1. Initial negotiation without VIRTIO_NET_F_CTRL_VLAN (table filled) 2. Renegotiation with VIRTIO_NET_F_CTRL_VLAN (table will not be cleared) The problem was exacerbated by commit 0caed25cd171 ("virtio: Call set_features during reset"), which triggered virtio_net_set_features() during device reset, exposing the bug whenever VIRTIO_NET_F_CTRL_VLAN was negotiated after a device reset. Solution -------- Fix the issue by initializing the table when virtio_net_set_features() is called to change the VIRTIO_NET_F_CTRL_VLAN bit of vdev->guest_features. This approach ensures the correct table state regardless of feature negotiation sequence by performing initialization in virtio_net_set_features() as QEMU did prior to commit 06b636a1e2ad ("virtio-net: do not reset vlan filtering at set_features"). This change still preserves the goal of the commit, which was to avoid resetting the table during migration, by checking whether the VIRTIO_NET_F_CTRL_VLAN bit of vdev->guest_features is being changed; vdev->guest_features is set before virtio_net_set_features() gets called during migration. It also avoids resetting the table when the driver sets a feature bitmask with no change for the VIRTIO_NET_F_CTRL_VLAN bit, which makes the operation idempotent and its semantics cleaner. Additionally, this change ensures the table is initialized after feature negotiation and before the DRIVER_OK status bit being set for compatibility with the Linux driver before commit 50c0ada627f5 ("virtio-net: fix race between ndo_open() and virtio_device_ready()"), which did not ensure to set the DRIVER_OK status bit before modifying the table. Fixes: 06b636a1e2ad ("virtio-net: do not reset vlan filtering at set_features") Cc: qemu-stable@nongnu.org Reported-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20250727-vlan-v3-1-bbee738619b1@rsg.ci.i.u-tokyo.ac.jp> Tested-by: Konstantin Shkolnyy <kshk@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01vhost: Do not abort on log-stop errorHanna Czenczek1-1/+2
Failing to stop logging in a vhost device is not exactly fatal. We can log such an error, but there is no need to abort the whole qemu process because of it. Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20250724125928.61045-3-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01vhost: Do not abort on log-start errorHanna Czenczek1-1/+2
Commit 3688fec8923 ("memory: Add Error** argument to .log_global_start() handler") enabled vhost_log_global_start() to return a proper error, but did not change it to do so; instead, it still aborts the whole process on error. This crash can be reproduced by e.g. killing a virtiofsd daemon before initiating migration. In such a case, qemu should not crash, but just make the attempted migration fail. Buglink: https://issues.redhat.com/browse/RHEL-94534 Reported-by: Tingting Mao <timao@redhat.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20250724125928.61045-2-hreitz@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-01virtio: fix off-by-one and invalid access in virtqueue_ordered_fillJonah Palmer1-6/+16
Commit b44135daa372 introduced virtqueue_ordered_fill for VIRTIO_F_IN_ORDER support but had a few issues: * Conditional while loop used 'steps <= max_steps' but should've been 'steps < max_steps' since reaching steps == max_steps would indicate that we didn't find an element, which is an error. Without this change, the code would attempt to read invalid data at an index outside of our search range. * Incremented 'steps' using the next chain's ndescs instead of the current one. This patch corrects the loop bounds and synchronizes 'steps' and index increments. We also add a defensive sanity check against malicious or invalid descriptor counts to avoid a potential infinite loop and DoS. Fixes: b44135daa372 ("virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support") Reported-by: terrynini <terrynini38514@gmail.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <20250721150208.2409779-1-jonah.palmer@oracle.com> Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.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>
2025-07-31target/arm: add support for 64-bit PMCCNTR in AArch32 modeAlex Richardson1-5/+24
In the PMUv3, a new AArch32 64-bit (MCRR/MRRC) accessor for the PMCCNTR was added. In QEMU we forgot to implement this, so only provide the 32-bit accessor. Since we have a 64-bit PMCCNTR sysreg for AArch64, adding the 64-bit AArch32 version is easy. We add the PMCCNTR to the v8_cp_reginfo because PMUv3 was added in the ARMv8 architecture. This is consistent with how we handle the existing PMCCNTR support, where we always implement it for all v7 CPUs. This is arguably something we should clean up so it is gated on ARM_FEATURE_PMU and/or an ID register check for the relevant PMU version, but we should do that as its own tidyup rather than being inconsistent between this PMCCNTR accessor and the others. Since the register name is the same as the 32-bit PMCCNTR, we set ARM_CP_NO_GDB on the 32-bit one to avoid generating an invalid GDB XML. See https://developer.arm.com/documentation/ddi0601/2024-06/AArch32-Registers/PMCCNTR--Performance-Monitors-Cycle-Count-Register?lang=en Note for potential backporting: * this code in cpregs-pmu.c will be in helper.c on stable branches that don't have commit ae2086426d37 Cc: qemu-stable@nongnu.org Signed-off-by: Alex Richardson <alexrichardson@google.com> Message-id: 20250725170136.145116-1-alexrichardson@google.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2025-07-31hw/intc/loongarch_ipi: Fix start fail with smp cpu < smp maxcpus on KVMSong Gao1-11/+16
QEMU start failed when smp cpu < smp maxcpus , because qemu send a NULL cpu to KVM, this patch adds a check for kvm_ipi_access_regs() to fix it. run with '-smp 1,maxcpus=4,sockets=4,cores=1,threads=1' we got: Unexpected error in kvm_device_access() at ../accel/kvm/kvm-all.c:3477: qemu-system-loongarch64: KVM_SET_DEVICE_ATTR failed: Group 1073741825 attr 0x0000000000010000: Invalid argument Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Message-ID: <20250725081213.3867592-1-gaosong@loongson.cn>
2025-07-31target/loongarch: Fix valid virtual address checkingBibo Mao1-2/+2
On LoongArch64 system, the high 32 bit of 64 bit virtual address should be 0x00000[0-7]yyy or 0xffff8yyy. The bit from 47 to 63 should be all 0 or all 1. Function get_physical_address() only checks bit 48 to 63, there will be problem with the following test case. On physical machine, there is bus error report and program exits abnormally. However on qemu TCG system emulation mode, the program runs normally. The virtual address 0xffff000000000000ULL + addr and addr are treated the same on TLB entry checking. This patch fixes this issue. void main() { void *addr, *addr1; int val; addr = malloc(100); *(int *)addr = 1; addr1 = 0xffff000000000000ULL + addr; val = *(int *)addr1; printf("val %d \n", val); } Cc: qemu-stable@nongnu.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-ID: <20250714015446.746163-1-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2025-07-30Merge tag 'pull-riscv-to-apply-20250730-2' of ↵Stefan Hajnoczi9-304/+90
https://github.com/alistair23/qemu into staging Third RISC-V PR for 10.1 * Fix pmp range wraparound on zero * Update FADT and MADT versions in ACPI tables * Fix target register read when source is inactive * Add riscv_hwprobe entry to linux-user strace list * Do not call GETPC() in check_ret_from_m_mode() * Revert "Generate strided vector loads/stores with tcg nodes." * Fix exception type when VU accesses supervisor CSRs * Restrict mideleg/medeleg/medelegh access to S-mode harts * Restrict midelegh access to S-mode harts # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmiJbsUACgkQr3yVEwxT # gBPXCxAAhgcGh/mbdk/DZM4Gx9WqbfjU/1jZR9FCld9im3GLtJfq7IdEcsUZzpNb # E4sp49lr99qoogKhh3exYhBl0/t0WBoT5mtHNPLFRD3LX2gw6EFQWnD8FN1D//sO # QvyulomYbmI/Ywf5n5SszF4BpOKh7nyUEZBp4PU6vLT5btsZheSoTyCypH4a7KAy # GMFNO+O1k6NEwkUqqiIb9Pg8NOp/R3TlNWOjS8fwqyPSU/F8/pzehJQu4WOMAyM8 # eGvqCZiwTg5CcLZfhQZ8dmqJ2qqI44FEzPjyq/Woq5hDmGDMl1iYhgjX5Ozy0X5j # m4Q+ZH0KIr18EkUD9z4fJbcQAMIm/2b90TShYon6+JYXX8DI8gUCvtg2vgsPAlnS # M6vgNT25qY8QZa/FbUGcP2+96AlaqX11jUou+TMuJMSr036gTP7gXux5hqYDrd0B # 4WL1XPcfNZshK5+LAQ+2uwQ9JcKlEaw/mkZHvHgYN7a03UynjCn0oFZtTYvaB4Qx # Du8Rm9VPlLp3e25VmOiObYyq2Cf6sQXlWomKLJbvfCj217ZXvjOwEjj8hBcg3zJ/ # 6ix/wmDic+YtwmYE7EaGZaExpV5ZjZog61jzMziilZrCJarAoguq0P9tThXGtViX # TqQcn1V391EfVZYbS3JBO08xmkkX2k7Ia//Th35nByLt7zzrRbs= # =pKhf # -----END PGP SIGNATURE----- # gpg: Signature made Tue 29 Jul 2025 21:00:53 EDT # gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [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: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013 * tag 'pull-riscv-to-apply-20250730-2' of https://github.com/alistair23/qemu: target/riscv: Restrict midelegh access to S-mode harts target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode harts target/riscv: Fix exception type when VU accesses supervisor CSRs riscv: Revert "Generate strided vector loads/stores with tcg nodes." target/riscv: do not call GETPC() in check_ret_from_m_mode() linux-user/strace.list: add riscv_hwprobe entry intc/riscv_aplic: Fix target register read when source is inactive tests/data/acpi/riscv64: Update expected FADT and MADT hw/riscv/virt-acpi-build.c: Update FADT and MADT versions bios-tables-test-allowed-diff.h: Allow RISC-V FADT and MADT changes target/riscv: Fix pmp range wraparound on zero Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-30target/riscv: Restrict midelegh access to S-mode hartsJay Chang1-2/+5
RISC-V AIA Spec states: "For a machine-level environment, extension Smaia encompasses all added CSRs and all modifications to interrupt response behavior that the AIA specifies for a hart, over all privilege levels. For a supervisor-level environment, extension Ssaia is essentially the same as Smaia except excluding the machine-level CSRs and behavior not directly visible to supervisor level." Since midelegh is an AIA machine-mode CSR, add Smaia extension check in aia_smode32 predicate. Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Nutty Liu<liujingqi@lanxincomputing.com> Message-ID: <20250701030021.99218-3-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30target/riscv: Restrict mideleg/medeleg/medelegh access to S-mode hartsJay Chang1-3/+3
RISC-V Privileged Spec states: "In harts with S-mode, the medeleg and mideleg registers must exist, and setting a bit in medeleg or mideleg will delegate the corresponding trap , when occurring in S-mode or U-mode, to the S-mode trap handler. In harts without S-mode, the medeleg and mideleg registers should not exist." Add smode predicate to ensure these CSRs are only accessible when S-mode is supported. Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Nutty Liu<liujingqi@lanxincomputing.com> Message-ID: <20250701030021.99218-2-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30target/riscv: Fix exception type when VU accesses supervisor CSRsXu Lu1-1/+1
When supervisor CSRs are accessed from VU-mode, a virtual instruction exception should be raised instead of an illegal instruction. Fixes: c1fbcecb3a (target/riscv: Fix csr number based privilege checking) Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Reviewed-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Message-ID: <20250708060720.7030-1-luxu.kernel@bytedance.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30riscv: Revert "Generate strided vector loads/stores with tcg nodes."Daniel Henrique Barboza1-273/+50
This reverts commit 28c12c1f2f50d7f7f1ebfc587c4777ecd50aac5b. As reported in [1] this commit is breaking Linux vector code, and although a simpler reproducer was provided, the fix itself isn't trivial due to the amount and the nature of the changes. And we really do not want to keep Linux broken while we work on it. The revert will fix Linux and will give us time to do a proper fix. [1] https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02525.html Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Eric Biggers <ebiggers@kernel.org> Message-ID: <20250710100525.372985-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30target/riscv: do not call GETPC() in check_ret_from_m_mode()Daniel Henrique Barboza1-6/+9
GETPC() should always be called from the top level helper, e.g. the first helper that is called by the translation code. We stopped doing that in commit 3157a553ec, and then we introduced problems when unwinding the exceptions being thrown by helper_mret(), as reported by [1]. Call GETPC() at the top level helper and pass the value along. [1] https://gitlab.com/qemu-project/qemu/-/issues/3020 Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: 3157a553ec ("target/riscv: Add Smrnmi mnret instruction") Closes: https://gitlab.com/qemu-project/qemu/-/issues/3020 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250714133739.1248296-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30linux-user/strace.list: add riscv_hwprobe entryDaniel Henrique Barboza1-0/+3
We're missing a strace entry for riscv_hwprobe, and using -strace will report it as "Unknown syscall 258". After this patch we'll have: $ ./build/qemu-riscv64 -strace test_mutex_riscv 110182 riscv_hwprobe(0x7f207efdc700,1,0,0,0,0) = 0 110182 brk(NULL) = 0x0000000000082000 (...) Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250728170633.113384-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30intc/riscv_aplic: Fix target register read when source is inactiveYang Jialong1-1/+5
The RISC-V Advanced interrupt Architecture: 4.5.16. Interrupt targets: If interrupt source i is inactive in this domain, register target[i] is read-only zero. Signed-off-by: Yang Jialong <z_bajeer@yeah.net> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250728055114.252024-1-z_bajeer@yeah.net> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30tests/data/acpi/riscv64: Update expected FADT and MADTSunil V L3-2/+0
Update the expected tables for the version change. /* * * ACPI Data Table [FACP] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue (in hex) */ [000h 0000 004h] Signature : "FACP" [Fixed ACPI Description Table (FADT)] [004h 0004 004h] Table Length : 00000114 [008h 0008 001h] Revision : 06 -[009h 0009 001h] Checksum : 13 +[009h 0009 001h] Checksum : 12 [00Ah 0010 006h] Oem ID : "BOCHS " [010h 0016 008h] Oem Table ID : "BXPC " [018h 0024 004h] Oem Revision : 00000001 [01Ch 0028 004h] Asl Compiler ID : "BXPC" [020h 0032 004h] Asl Compiler Revision : 00000001 [024h 0036 004h] FACS Address : 00000000 [028h 0040 004h] DSDT Address : 00000000 [02Ch 0044 001h] Model : 00 [02Dh 0045 001h] PM Profile : 00 [Unspecified] [02Eh 0046 002h] SCI Interrupt : 0000 [030h 0048 004h] SMI Command Port : 00000000 [034h 0052 001h] ACPI Enable Value : 00 [035h 0053 001h] ACPI Disable Value : 00 [036h 0054 001h] S4BIOS Command : 00 [037h 0055 001h] P-State Control : 00 @@ -86,33 +86,33 @@ Use APIC Physical Destination Mode (V4) : 0 Hardware Reduced (V5) : 1 Low Power S0 Idle (V5) : 0 [074h 0116 00Ch] Reset Register : [Generic Address Structure] [074h 0116 001h] Space ID : 00 [SystemMemory] [075h 0117 001h] Bit Width : 00 [076h 0118 001h] Bit Offset : 00 [077h 0119 001h] Encoded Access Width : 00 [Undefined/Legacy] [078h 0120 008h] Address : 0000000000000000 [080h 0128 001h] Value to cause reset : 00 [081h 0129 002h] ARM Flags (decoded below) : 0000 PSCI Compliant : 0 Must use HVC for PSCI : 0 -[083h 0131 001h] FADT Minor Revision : 05 +[083h 0131 001h] FADT Minor Revision : 06 [084h 0132 008h] FACS Address : 0000000000000000 [...] /* * * ACPI Data Table [APIC] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue (in hex) */ [000h 0000 004h] Signature : "APIC" [Multiple APIC Description Table (MADT)] [004h 0004 004h] Table Length : 00000074 -[008h 0008 001h] Revision : 06 -[009h 0009 001h] Checksum : B4 +[008h 0008 001h] Revision : 07 +[009h 0009 001h] Checksum : B3 [00Ah 0010 006h] Oem ID : "BOCHS " [010h 0016 008h] Oem Table ID : "BXPC " [...] Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Message-ID: <20250724110350.452828-4-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30hw/riscv/virt-acpi-build.c: Update FADT and MADT versionsSunil V L1-15/+10
RISC-V support is added only in ACPI 6.6. According to the ACPI 6.6 specification, the minor version of the Fixed ACPI Description Table (FADT) should be 6, and the Multiple APIC Description Table (MADT) should use revision 7. So, update the RISC-V FADT and MADT to reflect correct versions. Update the code comments to reflect ACPI 6.6 version details. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Message-ID: <20250724110350.452828-3-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30bios-tables-test-allowed-diff.h: Allow RISC-V FADT and MADT changesSunil V L1-0/+2
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Message-ID: <20250724110350.452828-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-30target/riscv: Fix pmp range wraparound on zeroVac Chen1-3/+4
pmp_is_in_range() prefers to match addresses within the interval [start, end]. To archieve this, pmpaddrX is decremented during the end address update. In TOR mode, a rule is ignored if its start address is greater than or equal to its end address. However, if pmpaddrX is set to 0, this decrement operation causes the calulated end address to wrap around to UINT_MAX. In this scenario, the address guard for this PMP entry would become ineffective. This patch addresses the issue by moving the guard check earlier, preventing the problematic wraparound when pmpaddrX is zero. Signed-off-by: Vac Chen <vacantron@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250706065554.42953-1-vacantron@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-07-29Update version for the v10.1.0-rc1 releasev10.1.0-rc1Stefan Hajnoczi1-1/+1
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-29Merge tag 'pull-qapi-2025-07-29' of https://repo.or.cz/qemu/armbru into stagingStefan Hajnoczi12-17/+13
QAPI patches for 2025-07-29 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmiIxAYSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTmvEP/iYxb+1mNWLimDE/Q0nO89KDBvxLMsIr # +Z/dB4GTffvfITX5bxlzf4CaivCBGxoV02kFnzhYVHNYZD9CFA7pPwKySg2kpOeh # NIrR7OAI9/W7H+uOyZslU78HhFSoKSfeYWssXnRyrXKPFXwyO7eJacXY9YlMz2ap # A1aQT843I60ldsW2/7oJ4wy/TwHnIwXwFyBXSuKq7447LpospXDXdNdaghEjxTsQ # LkYKcmSVgonCGnZf43OyiITdkXRdttZUoSQTMKJWBzg2UZkikqDeUt67t3XYkjWk # irvBnF0lt2oEbmyeuWNciEkI5/fyoENh0bNeLWDAKwEqDf2Dc3s19/SYV8y8N3pY # UuJRPSeJ4m2cNGv/5SU8C72GMMxcP50Usrk9JvJ1ZhS7C/rWXENC1CTm4uZDkJ0t # TJt0KC4lFW0wDoXMQv1zWSXqri6+n7Ts1iYsHq5jEpDPNvQB7TGHA1VN2FBipN2d # FXFCKWfpIxYbXsAh32mAUe1wiEkZTQdBZ/ZFFNRupMgg34B7X9gGg0kUBY161IfJ # x2N9/508kgCWppz5AR8Y3sniLGtWv0KMwfQcLK1392w8AcuhVSnmejY3SUaXlmGE # JRTqnMgo1EvS/7+We5OV1NuAbHbsk/bQUeN4ZDAkzQFAQscJvCQD/uD7jzY4xBFr # 4LhegQM8eG57 # =Opw0 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 29 Jul 2025 08:52:22 EDT # 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] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-qapi-2025-07-29' of https://repo.or.cz/qemu/armbru: MAINTAINERS: Cover docs/devel/qapi-domain.rst properly docs/qapi-domain: Fix typos tests/qapi-schema: Bury dead test case doc-non-first-section qapi/accelerator: Fix markup of heading qapi: Add more cross-references Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-29Merge tag 'hw-misc-20250729' of https://github.com/philmd/qemu into stagingStefan Hajnoczi9-34/+30
Misc HW patches - Fix MIPS MVPControl.EVP update - Fix qxl_unpack_chunks() chunk size calculation - Fix Cadence GEM register mask initialization - Fix AddressSpaceDispatch use after free - Fix building npcm7xx/npcm8xx bootroms - Include missing headers # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmiItwoACgkQ4+MsLN6t # wN5OGw//SFNgCvin6ic3H+QoUNwrRAH7eFuVfAKSKGopSqWf19imHy8rZl/8DYeo # WsCRUPkVcAGzgRHZFc+8VYGdSR5GW7AulSzHh7fGQ8EFNunu3cnGsDflVV6UjgRP # wnCfFuyrnyGfXVWkkjWYqCLI78AR0hB0Gp1E5nR4ZwGM4OhatDjKpYxWlRZbnjSA # pBArLw8eKUrq90RekVpsa15oF9eMU89HzDBfxYvk0tb4//BWBiWfgQ+cz7j9f1wC # wtTOEQ2BTkvGhqhe9VacV4YpQDXE9comlTked48GzHGqsAgp55NcB6FAR438qiG1 # 3z7LpL4LQn39+oC0S9cR2OahIGFEveOvGJoj014Iny4QR/ghNzt3F2Z9tgPISIKj # MhJ0Bu7K7X+RWikY9xiAu24ORrRd5O6EItgLsl+24vkySOKODZ85WdKtIx0DQ7Yj # rvRTkFDs/3K3kzMfZ20Jpeu7Bc74qUgsii27rivM/9rN0R9w+Br8MWLe0QSFalUe # 08NoRZMVuSPCWlvJGGb0SRYpVAZsZaE9Ucd8wQzEcjHdVu0/+7KQfACXrJ09Y8sq # lTgytCL8gO2jSEAh4cN/Ds1uBc8X5KKL32hNzRgddZVujqAuriBjAYEEk1pc7qe4 # yBxVkhASOpY53b1O2UqanajT2vY4T3JX5w+Jqn1HubZ/ZUwcK64= # =H2Ie # -----END PGP SIGNATURE----- # gpg: Signature made Tue 29 Jul 2025 07:56:58 EDT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * tag 'hw-misc-20250729' of https://github.com/philmd/qemu: hw/display/sm501: fix missing error-report.h roms/Makefile: fix npcmNxx_bootrom build rules system/physmem: fix use-after-free with dispatch hw/xen/passthrough: add missing error-report include hw/net/cadence_gem: fix register mask initialization migration: rename target.c to vfio.c hw/vfio/vfio-migration: Remove unnecessary 'qemu/typedefs.h' include hw/display/qxl-render: fix qxl_unpack_chunks() chunk size calculation target/mips: Only update MVPControl.EVP bit if executed by master VPE Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-29Merge tag 'pull-vfio-20250729' of https://github.com/legoater/qemu into stagingStefan Hajnoczi11-17/+48
vfio queue: * Fixed regression introduced by the `use-legacy-x86-rom` property * Fixed regressions on IGD passthrough in legacy mode * Fixed region mappings of sub-page BARs after CPR * Removed build of SEV on 32-bit hosts # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmiIaXIACgkQUaNDx8/7 # 7KHEUw//S/9+Aw7sHI0dLvYLLxMUfoDHY2B7nx/o3EgDMc3we4L19+t9d2RTxsc0 # QLz1wufhWn4gGIrb46fwqaU1ggu9cHi0o0E57cU+ZeADe/H9YRdFQ1q88yUzBARd # /exYAMV9L9NejzA/gvJDr2pZgf5ZZGY8H2MoiYw21z5nGJXlCS+1kXah7rZPHRcu # NEPw9jqab78jvHoFK1L1EaRCPN/qTaU8XGCFguDP0icFZCGnu4pIMHHQC6Btcjft # 2k5FDkQ9bzYqpq9W0KLimREBCnhmvBnCVSG/KTf/gsU222anGGgS8+80OABG7xrZ # 6LjFsBor2vKRhZ1JsL21BANg7M9iLPe3CB8KOgNdWl+RIkNfbUvt/tOqlAQgw9EI # JN7g9Ru1B0JVg18SHkTQ6/5eiWxnYRZvQA3R0BJXF23f2qqUtCm9VsQFUfYppc92 # Ci/hEtCXej8HoiJFK4gUHLYKRtk4DGbpiWgx1FYLid0ks5I+31m6x/PUMSvUbJez # oeKv5oCjvl3ORGrjpiDSA2O3gIEiMSru6jejN0RKEeRpSWOMcEsGPL7nySJaZElR # PrR/Cw+n4brTTIwUw7VnpeJnQ+XQbxD6wEzcDB7ZZ+gVs7BvmMT2LeDHzhPcaJuf # vDsTSss+YBSDCC8TCmcWPGOQB5SHPRNO/5aMPyYLulfa+VnHQmY= # =kKby # -----END PGP SIGNATURE----- # gpg: Signature made Tue 29 Jul 2025 02:25:54 EDT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@redhat.com>" [full] # gpg: aka "Cédric Le Goater <clg@kaod.org>" [full] # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-vfio-20250729' of https://github.com/legoater/qemu: vfio/igd: Fix VGA regions are not exposed in legacy mode vfio/igd: Require host VGA decode for legacy mode vfio: fix sub-page bar after cpr i386: Build SEV only for 64-bit target hw/i386: Fix 'use-legacy-x86-rom' property compatibility Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-07-29MAINTAINERS: Cover docs/devel/qapi-domain.rst properlyMarkus Armbruster1-0/+1
Section QAPI already covers it, and that's fine. It's missing from "Sphinx documentation configuration and build machinery". Add it there. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250729091642.3513895-3-armbru@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> [Improved commit message]
2025-07-29docs/qapi-domain: Fix typosMarkus Armbruster1-2/+2
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250729091642.3513895-2-armbru@redhat.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
2025-07-29tests/qapi-schema: Bury dead test case doc-non-first-sectionMarkus Armbruster3-7/+0
The test passed when it was added. However, the commit adding it neglected to make Meson aware of it, so it never ran automatically. The test stopped making sense when we changed headings markup, and ceased to pass then. It should've been removed then. Do that now. Fixes: 6c10778826a8 (docs/sphinx: remove special parsing for freeform sections) Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250724091742.1950167-3-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2025-07-29qapi/accelerator: Fix markup of headingMarkus Armbruster1-1/+3
The docs generated for qapi/accelerator.json shows text "= Accelerators" instead of a heading. This is because the patch that added the heading crossed with the commit that changed heading markup (commit 6c10778826a "docs/sphinx: remove special parsing for freeform sections"). Fix the markup. Fixes: 18da42ee4273 (qapi/accel: Move definitions related to accelerators in their own file) Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250724091742.1950167-2-armbru@redhat.com>