aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2024-06-05hw/intc/riscv_aplic: APLICs should add child earlier than realizeyang.zhang
Since only root APLICs can have hw IRQ lines, aplic->parent should be initialized first. Fixes: e8f79343cf ("hw/intc: Add RISC-V AIA APLIC device emulation") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: yang.zhang <yang.zhang@hexintek.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240409014445.278-1-gaoshanliukou@163.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c76b121840c6ca79dc6305a5f4bcf17c72217d9c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-30hw/intc/arm_gic: Fix handling of NS view of GICC_APR<n>Andrey Shumilin
In gic_cpu_read() and gic_cpu_write(), we delegate the handling of reading and writing the Non-Secure view of the GICC_APR<n> registers to functions gic_apr_ns_view() and gic_apr_write_ns_view(). Unfortunately we got the order of the arguments wrong, swapping the CPU number and the register number (which the compiler doesn't catch because they're both integers). Most guests probably didn't notice this bug because directly accessing the APR registers is typically something only done by firmware when it is doing state save for going into a sleep mode. Correct the mismatched call arguments. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: 51fd06e0ee ("hw/intc/arm_gic: Fix handling of GICC_APR<n>, GICC_NSAPR<n> registers") Signed-off-by: Andrey Shumilin <shum.sdl@nppct.ru> [PMM: Rewrote commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée<alex.bennee@linaro.org> (cherry picked from commit daafa78b297291fea36fb4daeed526705fa7c035) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-27hw/loongarch/virt: Fix FDT memory node address widthJiaxun Yang
Higher bits for memory nodes were omitted at qemu_fdt_setprop_cells. Cc: qemu-stable@nongnu.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20240520-loongarch-fdt-memnode-v1-1-5ea9be93911e@flygoat.com> Signed-off-by: Song Gao <gaosong@loongson.cn> (cherry picked from commit 6204af704a071ea68d3af55c0502b112a7af9546) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-27hw/loongarch: Fix fdt memory node wrong 'reg'Song Gao
The right fdt memory node like [1], not [2] [1] memory@0 { device_type = "memory"; reg = <0x00 0x00 0x00 0x10000000>; }; [2] memory@0 { device_type = "memory"; reg = <0x02 0x00 0x02 0x10000000>; }; Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Message-Id: <20240426091551.2397867-10-gaosong@loongson.cn> (cherry picked from commit b11f9814526b833b3a052be2559457b1affad7f5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-27hw/core/machine: move compatibility flags for VirtIO-net USO to machine 8.1Fiona Ebner
Migration from an 8.2 or 9.0 binary to an 8.1 binary with machine version 8.1 can fail with: > kvm: Features 0x1c0010130afffa7 unsupported. Allowed features: 0x10179bfffe7 > kvm: Failed to load virtio-net:virtio > kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net' > kvm: load of migration failed: Operation not permitted The series 53da8b5a99 virtio-net: Add support for USO features 9da1684954 virtio-net: Add USO flags to vhost support. f03e0cf63b tap: Add check for USO features 2ab0ec3121 tap: Add USO support to tap device. only landed in QEMU 8.2, so the compatibility flags should be part of machine version 8.1. Moving the flags unfortunately breaks forward migration with machine version 8.1 from a binary without this patch to a binary with this patch. Fixes: 53da8b5a99 ("virtio-net: Add support for USO features") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> (cherry picked from commit 9710401276a0eb2fc6d467d9abea1f5e3fe2c362) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-13hw/remote/vfio-user: Fix config space access byte orderMattias Nissler
PCI config space is little-endian, so on a big-endian host we need to perform byte swaps for values as they are passed to and received from the generic PCI config space access machinery. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: Mattias Nissler <mnissler@rivosinc.com> Message-ID: <20240507094210.300566-6-mnissler@rivosinc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit e6578f1f68a0e90789a841ada532c3e494c9a04c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-13hw/loongarch/virt: Fix memory leakSong Gao
The char pointer 'ramName' point to a block of memory, but never free it. Use 'g_autofree' to automatically free it. Resolves: Coverity CID 1544773 Fixes: 0cf1478d6 ("hw/loongarch: Add numa support") Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240507022239.3113987-1-gaosong@loongson.cn> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 54c52ec719fb8c83bbde54cb87b58688ab27c166) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in hw/loongarch/virt.c due to missing-in-8.2 v9.0.0-266-gd771ca1c10 "hw/loongarch: Move boot functions to boot.c")
2024-05-02hw/arm/npcm7xx: Store derivative OTP fuse key in little endianPhilippe Mathieu-Daudé
Use little endian for derivative OTP fuse key. Cc: qemu-stable@nongnu.org Fixes: c752bb079b ("hw/nvram: NPCM7xx OTP device model") Suggested-by: Avi Fishman <Avi.Fishman@nuvoton.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240422125813.1403-1-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit eb656a60fd93262b1e519b3162888bf261df7f68) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-02hw/dmax/xlnx_dpdma: fix handling of address_extension descriptor fieldsAlexandra Diupina
The DMA descriptor structures for this device have a set of "address extension" fields which extend the 32 bit source addresses with an extra 16 bits to give a 48 bit address: https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field However, we misimplemented this address extension in several ways: * we only extracted 12 bits of the extension fields, not 16 * we didn't shift the extension field up far enough * we accidentally did the shift as 32-bit arithmetic, which meant that we would have an overflow instead of setting bits [47:32] of the resulting 64-bit address Add a type cast and use extract64() instead of extract32() to avoid integer overflow on addition. Fix bit fields extraction according to documentation. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: d3c6369a96 ("introduce xlnx-dpdma") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Message-id: 20240428181131.23801-1-adiupina@astralinux.ru [PMM: adjusted commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4b00855f0ee2e2eee8fd2500ffef27c108be6dc3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-05-02hw/ufs: Fix buffer overflow bugJeuk Kim
It fixes the buffer overflow vulnerability in the ufs device. The bug was detected by sanitizers. You can reproduce it by: cat << EOF |\ qemu-system-x86_64 \ -display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \ file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \ ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0000058 0x1 0xa7 write 0xa 0x1 0x50 EOF Resolves: #2299 Fixes: 329f16624499 ("hw/ufs: Support for Query Transfer Requests") Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com> (cherry picked from commit f2c8aeb1afefcda92054c448b21fc59cdd99db30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-16ppc/spapr: Initialize max_cpus limit to SPAPR_IRQ_NR_IPIS.Harsh Prateek Bora
Initialize the machine specific max_cpus limit as per the maximum range of CPU IPIs available. Keeping between 4096 to 8192 will throw IRQ not free error due to XIVE/XICS limitation and keeping beyond 8192 will hit assert in tcg_region_init or spapr_xive_claim_irq. Logs: Without patch fix: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097 qemu-system-ppc64: IRQ 4096 is not free [root@host build]# On LPAR: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=8193 ** ERROR:../tcg/region.c:774:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Bail out! ERROR:../tcg/region.c:774:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Aborted (core dumped) [root@host build]# On x86: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=8193 qemu-system-ppc64: ../hw/intc/spapr_xive.c:596: spapr_xive_claim_irq: Assertion `lisn < xive->nr_irqs' failed. Aborted (core dumped) [root@host build]# With patch fix: [root@host build]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=4097 qemu-system-ppc64: Invalid SMP CPUs 4097. The max CPUs supported by machine 'pseries-8.2' is 4096 [root@host build]# Reported-by: Kowshik Jois <kowsjois@linux.ibm.com> Tested-by: Kowshik Jois <kowsjois@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit c4f91d7b7be76c47015521ab0109c6e998a369b0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-16ppc/spapr: Introduce SPAPR_IRQ_NR_IPIS to refer IRQ range for CPU IPIs.Harsh Prateek Bora
spapr_irq_init currently uses existing macro SPAPR_XIRQ_BASE to refer to the range of CPU IPIs during initialization of nr-irqs property. It is more appropriate to have its own define which can be further reused as appropriate for correct interpretation. Suggested-by: Cedric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Kowshik Jois <kowsjois@linux.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit 2df5c1f5b014126595a26c6797089d284a3b211c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-16hw/pci-host/ppc440_pcix: Do not expose a bridge device on PCI busBALATON Zoltan
Real 460EX SoC apparently does not expose a bridge device and having it appear on PCI bus confuses an AmigaOS file system driver that uses this to detect which machine it is running on. Cc: qemu-stable@nongnu.org Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240411192443.B4D644E6026@zero.eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 6e4aceba2079e3df42edc89d44f4ee02343bb09e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-16hw/isa/vt82c686: Keep track of PIRQ/PINT pins separatelyBALATON Zoltan
Move calculation of mask after the switch which sets the function number for PIRQ/PINT pins to make sure the state of these pins are kept track of separately and IRQ is raised if any of them is active. Cc: qemu-stable@nongnu.org Fixes: 7e01bd80c1 hw/isa/vt82c686: Bring back via_isa_set_irq() Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240410222543.0EA534E6005@zero.eik.bme.hu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit f33274265a242df5d9fdb00915fe72fbb1b2a3c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-15virtio-pci: fix use of a released vectorCindy Lu
During the booting process of the non-standard image, the behavior of the called function in qemu is as follows: 1. vhost_net_stop() was triggered by guest image. This will call the function virtio_pci_set_guest_notifiers() with assgin= false, virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0 2. virtio_reset() was triggered, this will set configure vector to VIRTIO_NO_VECTOR 3.vhost_net_start() was called (at this time, the configure vector is still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() with assgin=true, so the irqfd for vector 0 is still not "init" during this process 4. The system continues to boot and sets the vector back to 0. After that msix_fire_vector_notifier() was triggered to unmask the vector 0 and meet the crash To fix the issue, we need to support changing the vector after VIRTIO_CONFIG_S_DRIVER_OK is set. (gdb) bt 0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 1 0x00007fc87148ec53 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 2 0x00007fc87143e956 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 3 0x00007fc8714287f4 in __GI_abort () at abort.c:79 4 0x00007fc87142871b in __assert_fail_base (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d "../accel/kvm/kvm-all.c", line=1837, function=<optimized out>) at assert.c:92 5 0x00007fc871437536 in __GI___assert_fail (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0 <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101 6 0x0000560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at ../accel/kvm/kvm-all.c:1837 7 0x0000560640c98f8e in virtio_pci_one_vector_unmask (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=..., n=0x560643c6e4c8) at ../hw/virtio/virtio-pci.c:1005 8 0x0000560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00, vector=0, msg=...) at ../hw/virtio/virtio-pci.c:1070 9 0x0000560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00, vector=0, is_masked=false) at ../hw/pci/msix.c:120 10 0x0000560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, vector=0, was_masked=true) at ../hw/pci/msix.c:140 11 0x0000560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, addr=12, val=0, size=4) at ../hw/pci/msix.c:231 12 0x0000560640f26d83 in memory_region_write_accessor (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0, mask=4294967295, attrs=...) at ../system/memory.c:497 13 0x0000560640f270a6 in access_with_adjusted_size (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1, access_size_max=4, access_fn=0x560640f26c8d <memory_region_write_accessor>, mr=0x560643c66540, attrs=...) at ../system/memory.c:573 14 0x0000560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540, addr=12, data=0, op=MO_32, attrs=...) at ../system/memory.c:1521 15 0x0000560640f37bac in flatview_write_continue (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, len=4, addr1=12, l=4, mr=0x560643c66540) at ../system/physmem.c:2714 16 0x0000560640f37d0f in flatview_write (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4) at ../system/physmem.c:2756 17 0x0000560640f380bf in address_space_write (as=0x560642161ae0 <address_space_memory>, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4) at ../system/physmem.c:2863 18 0x0000560640f3812c in address_space_rw (as=0x560642161ae0 <address_space_memory>, addr=4273803276, attrs=..., buf=0x7fc871e9c028, len=4, is_write=true) at ../system/physmem.c:2873 --Type <RET> for more, q to quit, c to continue without paging-- 19 0x0000560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at ../accel/kvm/kvm-all.c:2915 20 0x0000560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at ../accel/kvm/kvm-accel-ops.c:51 21 0x00005606411949f4 in qemu_thread_start (args=0x560642f292b0) at ../util/qemu-thread-posix.c:541 22 0x00007fc87148cdcd in start_thread (arg=<optimized out>) at pthread_create.c:442 23 0x00007fc871512630 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) MST: coding style and typo fixups Fixes: f9a09ca3ea ("vhost: add support for configure interrupt") Cc: qemu-stable@nongnu.org Signed-off-by: Cindy Lu <lulu@redhat.com> Message-ID: <2321ade5f601367efe7380c04e3f61379c59b48f.1713173550.git.mst@redhat.com> Cc: Lei Yang <leiyang@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Cindy Lu <lulu@redhat.com> (cherry picked from commit 2ce6cff94df2650c460f809e5ad263f1d22507c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/audio/virtio-snd: Remove unused assignmentPhilippe Mathieu-Daudé
Coverity reported: >>> CID 1542933: Code maintainability issues (UNUSED_VALUE) >>> CID 1542934: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "NULL" to "stream" here, but that stored value is overwritten before it can be used. Simply remove the unused assignments. Resolves: Coverity CID 1542933 Resolves: Coverity CID 1542934 Fixes: 731655f87f ("virtio-snd: rewrite invalid tx/rx message handling") Fixes: 20cd0c8655 ("virtio-snd: rewrite invalid tx/rx message handling" in stable-8.2) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20240410053712.34747-1-philmd@linaro.org> (cherry picked from commit dcb0a1ac03d6b5ba6c7fcbe467f0215738006113) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/net/net_tx_pkt: Fix overrun in update_sctp_checksum()Philippe Mathieu-Daudé
If a fragmented packet size is too short, do not try to calculate its checksum. Reproduced using: $ cat << EOF | qemu-system-i386 -display none -nodefaults \ -machine q35,accel=qtest -m 32M \ -device igb,netdev=net0 \ -netdev user,id=net0 \ -qtest stdio outl 0xcf8 0x80000810 outl 0xcfc 0xe0000000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0000403 0x1 0x02 writel 0xe0003808 0xffffffff write 0xe000381a 0x1 0x5b write 0xe000381b 0x1 0x00 EOF Assertion failed: (offset == 0), function iov_from_buf_full, file util/iov.c, line 39. #1 0x5575e81e952a in iov_from_buf_full qemu/util/iov.c:39:5 #2 0x5575e6500768 in net_tx_pkt_update_sctp_checksum qemu/hw/net/net_tx_pkt.c:144:9 #3 0x5575e659f3e1 in igb_setup_tx_offloads qemu/hw/net/igb_core.c:478:11 #4 0x5575e659f3e1 in igb_tx_pkt_send qemu/hw/net/igb_core.c:552:10 #5 0x5575e659f3e1 in igb_process_tx_desc qemu/hw/net/igb_core.c:671:17 #6 0x5575e659f3e1 in igb_start_xmit qemu/hw/net/igb_core.c:903:9 #7 0x5575e659f3e1 in igb_set_tdt qemu/hw/net/igb_core.c:2812:5 #8 0x5575e657d6a4 in igb_core_write qemu/hw/net/igb_core.c:4248:9 Fixes: CVE-2024-3567 Cc: qemu-stable@nongnu.org Reported-by: Zheyu Ma <zheyuma97@gmail.com> Fixes: f199b13bc1 ("igb: Implement Tx SCTP CSO") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2273 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20240410070459.49112-1-philmd@linaro.org> (cherry picked from commit 83ddb3dbba2ee0f1767442ae6ee665058aeb1093) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/sd/sdhci: Do not update TRNMOD when Command Inhibit (DAT) is setPhilippe Mathieu-Daudé
Per "SD Host Controller Standard Specification Version 3.00": * 2.2.5 Transfer Mode Register (Offset 00Ch) Writes to this register shall be ignored when the Command Inhibit (DAT) in the Present State register is 1. Do not update the TRNMOD register when Command Inhibit (DAT) bit is set to avoid the present-status register going out of sync, leading to malicious guest using DMA mode and overflowing the FIFO buffer: $ cat << EOF | qemu-system-i386 \ -display none -nographic -nodefaults \ -machine accel=qtest -m 512M \ -device sdhci-pci,sd-spec-version=3 \ -device sd-card,drive=mydrive \ -drive if=none,index=0,file=null-co://,format=raw,id=mydrive \ -qtest stdio outl 0xcf8 0x80001013 outl 0xcfc 0x91 outl 0xcf8 0x80001001 outl 0xcfc 0x06000000 write 0x9100002c 0x1 0x05 write 0x91000058 0x1 0x16 write 0x91000005 0x1 0x04 write 0x91000028 0x1 0x08 write 0x16 0x1 0x21 write 0x19 0x1 0x20 write 0x9100000c 0x1 0x01 write 0x9100000e 0x1 0x20 write 0x9100000f 0x1 0x00 write 0x9100000c 0x1 0x00 write 0x91000020 0x1 0x00 EOF Stack trace (part): ================================================================= ==89993==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000029900 at pc 0x55d5f885700d bp 0x7ffc1e1e9470 sp 0x7ffc1e1e9468 WRITE of size 1 at 0x615000029900 thread T0 #0 0x55d5f885700c in sdhci_write_dataport hw/sd/sdhci.c:564:39 #1 0x55d5f8849150 in sdhci_write hw/sd/sdhci.c:1223:13 #2 0x55d5fa01db63 in memory_region_write_accessor system/memory.c:497:5 #3 0x55d5fa01d245 in access_with_adjusted_size system/memory.c:573:18 #4 0x55d5fa01b1a9 in memory_region_dispatch_write system/memory.c:1521:16 #5 0x55d5fa09f5c9 in flatview_write_continue system/physmem.c:2711:23 #6 0x55d5fa08f78b in flatview_write system/physmem.c:2753:12 #7 0x55d5fa08f258 in address_space_write system/physmem.c:2860:18 ... 0x615000029900 is located 0 bytes to the right of 512-byte region [0x615000029700,0x615000029900) allocated by thread T0 here: #0 0x55d5f7237b27 in __interceptor_calloc #1 0x7f9e36dd4c50 in g_malloc0 #2 0x55d5f88672f7 in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 #3 0x55d5f844b582 in pci_qdev_realize hw/pci/pci.c:2092:9 #4 0x55d5fa2ee74b in device_set_realized hw/core/qdev.c:510:13 #5 0x55d5fa325bfb in property_set_bool qom/object.c:2358:5 #6 0x55d5fa31ea45 in object_property_set qom/object.c:1472:5 #7 0x55d5fa332509 in object_property_set_qobject om/qom-qobject.c:28:10 #8 0x55d5fa31f6ed in object_property_set_bool qom/object.c:1541:15 #9 0x55d5fa2e2948 in qdev_realize hw/core/qdev.c:292:12 #10 0x55d5f8eed3f1 in qdev_device_add_from_qdict system/qdev-monitor.c:719:10 #11 0x55d5f8eef7ff in qdev_device_add system/qdev-monitor.c:738:11 #12 0x55d5f8f211f0 in device_init_func system/vl.c:1200:11 #13 0x55d5fad0877d in qemu_opts_foreach util/qemu-option.c:1135:14 #14 0x55d5f8f0df9c in qemu_create_cli_devices system/vl.c:2638:5 #15 0x55d5f8f0db24 in qmp_x_exit_preconfig system/vl.c:2706:5 #16 0x55d5f8f14dc0 in qemu_init system/vl.c:3737:9 ... SUMMARY: AddressSanitizer: heap-buffer-overflow hw/sd/sdhci.c:564:39 in sdhci_write_dataport Add assertions to ensure the fifo_buffer[] is not overflowed by malicious accesses to the Buffer Data Port register. Fixes: CVE-2024-3447 Cc: qemu-stable@nongnu.org Fixes: d7dfca0807 ("hw/sdhci: introduce standard SD host controller") Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58813 Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <CAFEAcA9iLiv1XGTGKeopgMa8Y9+8kvptvsb8z2OBeuy+5=NUfg@mail.gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409145524.27913-1-philmd@linaro.org> (cherry picked from commit 9e4b27ca6bf4974f169bbca7f3dca117b1208b6f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/net/lan9118: Fix overflow in MIL TX FIFOPhilippe Mathieu-Daudé
When the MAC Interface Layer (MIL) transmit FIFO is full, truncate the packet, and raise the Transmitter Error (TXE) flag. Broken since model introduction in commit 2a42499017 ("LAN9118 emulation"). When using the reproducer from https://gitlab.com/qemu-project/qemu/-/issues/2267 we get: hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for type 'uint8_t[2048]' (aka 'unsigned char[2048]')     #0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43     #1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9     #2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9     #3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5     #4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18     #5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16     #6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18     #7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19     #8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12     #9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18 ... [*] LAN9118 DS00002266B.pdf, Table 5.3.3 "INTERRUPT STATUS REGISTER" Cc: qemu-stable@nongnu.org Reported-by: Will Lester Reported-by: Chuhong Yuan <hslester96@gmail.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2267 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-3-philmd@linaro.org> (cherry picked from commit ad766d603f39888309cfb1433ba2de1d0e9e4f58) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/net/lan9118: Replace magic '2048' value by MIL_TXFIFO_SIZE definitionPhilippe Mathieu-Daudé
The magic 2048 is explained in the LAN9211 datasheet (DS00002414A) in chapter 1.4, "10/100 Ethernet MAC": The MAC Interface Layer (MIL), within the MAC, contains a 2K Byte transmit and a 128 Byte receive FIFO which is separate from the TX and RX FIFOs. [...] Note, the use of the constant in lan9118_receive() reveals that our implementation is using the same buffer for both tx and rx. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240409133801.23503-2-philmd@linaro.org> (cherry picked from commit a45223467e4e185fff1c76a6483784fa379ded77) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/misc/applesmc: Fix memory leak in reset() handlerPhilippe Mathieu-Daudé
AppleSMCData is allocated with g_new0() in applesmc_add_key(): release it with g_free(). Leaked since commit 1ddda5cd36 ("AppleSMC device emulation"). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2272 Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240408095217.57239-3-philmd@linaro.org> (cherry picked from commit fc09ff2979defdcf8d00c2db94022d5d610e36ba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/block/nand: Fix out-of-bound access in NAND block bufferPhilippe Mathieu-Daudé
nand_command() and nand_getio() don't check @offset points into the block, nor the available data length (s->iolen) is not negative. In order to fix: - check the offset is in range in nand_blk_load_NAND_PAGE_SIZE(), - do not set @iolen if blk_load() failed. Reproducer: $ cat << EOF | qemu-system-arm -machine tosa \ -monitor none -serial none \ -display none -qtest stdio write 0x10000111 0x1 0xca write 0x10000104 0x1 0x47 write 0x1000ca04 0x1 0xd7 write 0x1000ca01 0x1 0xe0 write 0x1000ca04 0x1 0x71 write 0x1000ca00 0x1 0x50 write 0x1000ca04 0x1 0xd7 read 0x1000ca02 0x1 write 0x1000ca01 0x1 0x10 EOF ================================================================= ==15750==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000000de0 at pc 0x560e61557210 bp 0x7ffcfc4a59f0 sp 0x7ffcfc4a59e8 READ of size 1 at 0x61f000000de0 thread T0 #0 0x560e6155720f in mem_and hw/block/nand.c:101:20 #1 0x560e6155ac9c in nand_blk_write_512 hw/block/nand.c:663:9 #2 0x560e61544200 in nand_command hw/block/nand.c:293:13 #3 0x560e6153cc83 in nand_setio hw/block/nand.c:520:13 #4 0x560e61a0a69e in tc6393xb_nand_writeb hw/display/tc6393xb.c:380:13 #5 0x560e619f9bf7 in tc6393xb_writeb hw/display/tc6393xb.c:524:9 #6 0x560e647c7d03 in memory_region_write_accessor softmmu/memory.c:492:5 #7 0x560e647c7641 in access_with_adjusted_size softmmu/memory.c:554:18 #8 0x560e647c5f66 in memory_region_dispatch_write softmmu/memory.c:1514:16 #9 0x560e6485409e in flatview_write_continue softmmu/physmem.c:2825:23 #10 0x560e648421eb in flatview_write softmmu/physmem.c:2867:12 #11 0x560e64841ca8 in address_space_write softmmu/physmem.c:2963:18 #12 0x560e61170162 in qemu_writeb tests/qtest/videzzo/videzzo_qemu.c:1080:5 #13 0x560e6116eef7 in dispatch_mmio_write tests/qtest/videzzo/videzzo_qemu.c:1227:28 0x61f000000de0 is located 0 bytes to the right of 3424-byte region [0x61f000000080,0x61f000000de0) allocated by thread T0 here: #0 0x560e611276cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 #1 0x7f7959a87e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) #2 0x560e64b98871 in object_new qom/object.c:749:12 #3 0x560e64b5d1a1 in qdev_new hw/core/qdev.c:153:19 #4 0x560e61547ea5 in nand_init hw/block/nand.c:639:11 #5 0x560e619f8772 in tc6393xb_init hw/display/tc6393xb.c:558:16 #6 0x560e6390bad2 in tosa_init hw/arm/tosa.c:250:12 SUMMARY: AddressSanitizer: heap-buffer-overflow hw/block/nand.c:101:20 in mem_and ==15750==ABORTING Broken since introduction in commit 3e3d5815cb ("NAND Flash memory emulation and ECC calculation helpers for use by NAND controllers"). Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1445 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1446 Reported-by: Qiang Liu <cyruscyliu@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-4-philmd@linaro.org> (cherry picked from commit d39fdfff348fdf00173b7a58e935328a64db7d28) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/block/nand: Have blk_load() take unsigned offset and return booleanPhilippe Mathieu-Daudé
Negative offset is meaningless, use unsigned type. Return a boolean value indicating success. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-3-philmd@linaro.org> (cherry picked from commit 2e3e09b368001f7eaeeca7a9b49cb1f0c9092d85) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/block/nand: Factor nand_load_iolen() method outPhilippe Mathieu-Daudé
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240409135944.24997-2-philmd@linaro.org> (cherry picked from commit 7a86544f286d8af4fa5251101c1026ddae92cc3d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/virtio/virtio-crypto: Protect from DMA re-entrancy bugsPhilippe Mathieu-Daudé
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed. Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Suggested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-5-philmd@linaro.org> (cherry picked from commit f4729ec39ad97a42ceaa7b5697f84f440ea6e5dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/char/virtio-serial-bus: Protect from DMA re-entrancy bugsPhilippe Mathieu-Daudé
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed. Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Suggested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-4-philmd@linaro.org> (cherry picked from commit b4295bff25f7b50de1d9cc94a9c6effd40056bca) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/display/virtio-gpu: Protect from DMA re-entrancy bugsPhilippe Mathieu-Daudé
Replace qemu_bh_new_guarded() by virtio_bh_new_guarded() so the bus and device use the same guard. Otherwise the DMA-reentrancy protection can be bypassed: $ cat << EOF | qemu-system-i386 -display none -nodefaults \ -machine q35,accel=qtest \ -m 512M \ -device virtio-gpu \ -qtest stdio outl 0xcf8 0x80000820 outl 0xcfc 0xe0004000 outl 0xcf8 0x80000804 outw 0xcfc 0x06 write 0xe0004030 0x4 0x024000e0 write 0xe0004028 0x1 0xff write 0xe0004020 0x4 0x00009300 write 0xe000401c 0x1 0x01 write 0x101 0x1 0x04 write 0x103 0x1 0x1c write 0x9301c8 0x1 0x18 write 0x105 0x1 0x1c write 0x107 0x1 0x1c write 0x109 0x1 0x1c write 0x10b 0x1 0x00 write 0x10d 0x1 0x00 write 0x10f 0x1 0x00 write 0x111 0x1 0x00 write 0x113 0x1 0x00 write 0x115 0x1 0x00 write 0x117 0x1 0x00 write 0x119 0x1 0x00 write 0x11b 0x1 0x00 write 0x11d 0x1 0x00 write 0x11f 0x1 0x00 write 0x121 0x1 0x00 write 0x123 0x1 0x00 write 0x125 0x1 0x00 write 0x127 0x1 0x00 write 0x129 0x1 0x00 write 0x12b 0x1 0x00 write 0x12d 0x1 0x00 write 0x12f 0x1 0x00 write 0x131 0x1 0x00 write 0x133 0x1 0x00 write 0x135 0x1 0x00 write 0x137 0x1 0x00 write 0x139 0x1 0x00 write 0xe0007003 0x1 0x00 EOF ... ================================================================= ==276099==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000011178 at pc 0x562cc3b736c7 bp 0x7ffed49dee60 sp 0x7ffed49dee58 READ of size 8 at 0x60d000011178 thread T0 #0 0x562cc3b736c6 in virtio_gpu_ctrl_response hw/display/virtio-gpu.c:180:42 #1 0x562cc3b7c40b in virtio_gpu_ctrl_response_nodata hw/display/virtio-gpu.c:192:5 #2 0x562cc3b7c40b in virtio_gpu_simple_process_cmd hw/display/virtio-gpu.c:1015:13 #3 0x562cc3b82873 in virtio_gpu_process_cmdq hw/display/virtio-gpu.c:1050:9 #4 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #5 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #6 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5 #7 0x562cc4a8a2da in aio_ctx_dispatch util/async.c:358:5 #8 0x7f36840547a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) #9 0x562cc4a8b753 in glib_pollfds_poll util/main-loop.c:290:9 #10 0x562cc4a8b753 in os_host_main_loop_wait util/main-loop.c:313:5 #11 0x562cc4a8b753 in main_loop_wait util/main-loop.c:592:11 #12 0x562cc3938186 in qemu_main_loop system/runstate.c:782:9 #13 0x562cc43b7af5 in qemu_default_main system/main.c:37:14 #14 0x7f3683a6c189 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #15 0x7f3683a6c244 in __libc_start_main csu/../csu/libc-start.c:381:3 #16 0x562cc2a58ac0 in _start (qemu-system-i386+0x231bac0) 0x60d000011178 is located 56 bytes inside of 136-byte region [0x60d000011140,0x60d0000111c8) freed by thread T0 here: #0 0x562cc2adb662 in __interceptor_free (qemu-system-i386+0x239e662) #1 0x562cc3b86b21 in virtio_gpu_reset hw/display/virtio-gpu.c:1524:9 #2 0x562cc416e20e in virtio_reset hw/virtio/virtio.c:2145:9 #3 0x562cc37c5644 in virtio_pci_reset hw/virtio/virtio-pci.c:2249:5 #4 0x562cc4233758 in memory_region_write_accessor system/memory.c:497:5 #5 0x562cc4232eea in access_with_adjusted_size system/memory.c:573:18 previously allocated by thread T0 here: #0 0x562cc2adb90e in malloc (qemu-system-i386+0x239e90e) #1 0x7f368405a678 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5a678) #2 0x562cc4163ffc in virtqueue_split_pop hw/virtio/virtio.c:1612:12 #3 0x562cc4163ffc in virtqueue_pop hw/virtio/virtio.c:1783:16 #4 0x562cc3b91a95 in virtio_gpu_handle_ctrl hw/display/virtio-gpu.c:1112:15 #5 0x562cc4a85514 in aio_bh_call util/async.c:169:5 #6 0x562cc4a85c52 in aio_bh_poll util/async.c:216:13 #7 0x562cc4a1a79b in aio_dispatch util/aio-posix.c:423:5 SUMMARY: AddressSanitizer: heap-use-after-free hw/display/virtio-gpu.c:180:42 in virtio_gpu_ctrl_response With this change, the same reproducer triggers: qemu-system-i386: warning: Blocked re-entrant IO on MemoryRegion: virtio-pci-common-virtio-gpu at addr: 0x6 Fixes: CVE-2024-3446 Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Yongkang Jia <kangel@zju.edu.cn> Reported-by: Xiao Lei <nop.leixiao@gmail.com> Reported-by: Yiming Tao <taoym@zju.edu.cn> Buglink: https://bugs.launchpad.net/qemu/+bug/1888606 Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-3-philmd@linaro.org> (cherry picked from commit ba28e0ff4d95b56dc334aac2730ab3651ffc3132) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-10hw/virtio: Introduce virtio_bh_new_guarded() helperPhilippe Mathieu-Daudé
Introduce virtio_bh_new_guarded(), similar to qemu_bh_new_guarded() but using the transport memory guard, instead of the device one (there can only be one virtio device per virtio bus). Inspired-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240409105537.18308-2-philmd@linaro.org> (cherry picked from commit ec0504b989ca61e03636384d3602b7bf07ffe4da) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-09virtio-snd: rewrite invalid tx/rx message handlingManos Pitsidianakis
The current handling of invalid virtqueue elements inside the TX/RX virt queue handlers is wrong. They are added in a per-stream invalid queue to be processed after the handler is done examining each message, but the invalid message might not be specifying any stream_id; which means it's invalid to add it to any stream->invalid queue since stream could be NULL at this point. This commit moves the invalid queue to the VirtIOSound struct which guarantees there will always be a valid temporary place to store them inside the tx/rx handlers. The queue will be emptied before the handler returns, so the queue must be empty at any other point of the device's lifetime. Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <virtio-snd-rewrite-invalid-tx-rx-message-handling-v1.manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 731655f87f319fd06f27282c6cafbc2467ac8045) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-09virtio-snd: Enhance error handling for invalid transfersZheyu Ma
This patch improves error handling in virtio_snd_handle_tx_xfer() and virtio_snd_handle_rx_xfer() in the VirtIO sound driver. Previously, 'goto' statements were used for error paths, leading to unnecessary processing and potential null pointer dereferences. Now, 'continue' is used to skip the rest of the current loop iteration for errors such as message size discrepancies or null streams, reducing crash risks. ASAN log illustrating the issue addressed: ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4 #0 0x57cea39967b8 in qemu_mutex_lock_impl qemu/util/qemu-thread-posix.c:92:5 #1 0x57cea128c462 in qemu_mutex_lock qemu/include/qemu/thread.h:122:5 #2 0x57cea128d72f in qemu_lockable_lock qemu/include/qemu/lockable.h:95:5 #3 0x57cea128c294 in qemu_lockable_auto_lock qemu/include/qemu/lockable.h:105:5 #4 0x57cea1285eb2 in virtio_snd_handle_rx_xfer qemu/hw/audio/virtio-snd.c:1026:9 #5 0x57cea2caebbc in virtio_queue_notify_vq qemu/hw/virtio/virtio.c:2268:9 #6 0x57cea2cae412 in virtio_queue_host_notifier_read qemu/hw/virtio/virtio.c:3671:9 #7 0x57cea39822f1 in aio_dispatch_handler qemu/util/aio-posix.c:372:9 #8 0x57cea3979385 in aio_dispatch_handlers qemu/util/aio-posix.c:414:20 #9 0x57cea3978eb1 in aio_dispatch qemu/util/aio-posix.c:424:5 #10 0x57cea3a1eede in aio_ctx_dispatch qemu/util/async.c:360:5 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20240322110827.568412-1-zheyuma97@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a45f09935c88ae352a5ec120418a8b2b36ec1daa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-09vdpa-dev: Fix the issue of device status not updating when configuration ↵lyx634449800
interruption is triggered The set_config callback function vhost_vdpa_device_get_config in vdpa-dev does not fetch the current device status from the hardware device, causing the guest os to not receive the latest device status information. The hardware updates the config status of the vdpa device and then notifies the os. The guest os receives an interrupt notification, triggering a get_config access in the kernel, which then enters qemu internally. Ultimately, the vhost_vdpa_device_get_config function of vdpa-dev is called One scenario encountered is when the device needs to bring down the vdpa net device. After modifying the status field of virtio_net_config in the hardware, it sends an interrupt notification. However, the guest os always receives the STATUS field as VIRTIO_NET_S_LINK_UP. Signed-off-by: Yuxue Liu <yuxue.liu@jaguarmicro.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20240408020003.1979-1-yuxue.liu@jaguarmicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 6ae72f609a21cfc56bf655cd4bcded5d07691ce7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-09hw/virtio: Fix packed virtqueue flush used_idxWafer
In the event of writing many chains of descriptors, the device must write just the id of the last buffer in the descriptor chain, skip forward the number of descriptors in the chain, and then repeat the operations for the rest of chains. Current QEMU code writes all the buffer ids consecutively, and then skips all the buffers altogether. This is a bug, and can be reproduced with a VirtIONet device with _F_MRG_RXBUB and without _F_INDIRECT_DESC: If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature but not the VIRTIO_RING_F_INDIRECT_DESC feature, 'VirtIONetQueue->rx_vq' will use the merge feature to store data in multiple 'elems'. The 'num_buffers' in the virtio header indicates how many elements are merged. If the value of 'num_buffers' is greater than 1, all the merged elements will be filled into the descriptor ring. The 'idx' of the elements should be the value of 'vq->used_idx' plus 'ndescs'. Fixes: 86044b24e8 ("virtio: basic packed virtqueue support") Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Wafer <wafer@jaguarmicro.com> Message-Id: <20240407015451.5228-2-wafer@jaguarmicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2d9a31b3c27311eca1682cb2c076d7a300441960) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-09block/virtio-blk: Fix memory leak from virtio_blk_zone_reportZheyu Ma
This modification ensures that in scenarios where the buffer size is insufficient for a zone report, the function will now properly set an error status and proceed to a cleanup label, instead of merely returning. The following ASAN log reveals it: ==1767400==ERROR: LeakSanitizer: detected memory leaks Direct leak of 312 byte(s) in 1 object(s) allocated from: #0 0x64ac7b3280cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 #1 0x735b02fb9738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) #2 0x64ac7d23be96 in virtqueue_split_pop hw/virtio/virtio.c:1612:12 #3 0x64ac7d23728a in virtqueue_pop hw/virtio/virtio.c:1783:16 #4 0x64ac7cfcaacd in virtio_blk_get_request hw/block/virtio-blk.c:228:27 #5 0x64ac7cfca7c7 in virtio_blk_handle_vq hw/block/virtio-blk.c:1123:23 #6 0x64ac7cfecb95 in virtio_blk_handle_output hw/block/virtio-blk.c:1157:5 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Message-id: 20240404120040.1951466-1-zheyuma97@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit bbdf9023665f409113cb07b463732861af63fb47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-03hw/net/virtio-net: fix qemu set used ring flag even vhost startedYajun Wu
When vhost-user or vhost-kernel is handling virtio net datapath, QEMU should not touch used ring. But with vhost-user socket reconnect scenario, in a very rare case (has pending kick event). VRING_USED_F_NO_NOTIFY is set by QEMU in following code path: #0 virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:511 #1 0x0000559d6dbf033b in virtio_queue_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576 #2 0x0000559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0, vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801 #3 0x0000559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at ../hw/virtio/virtio.c:2248 #4 0x0000559d6dbf79da in virtio_queue_host_notifier_read (n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525 #5 0x0000559d6d9a5814 in virtio_bus_cleanup_host_notifier (bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321 #6 0x0000559d6dbf83c9 in virtio_device_stop_ioeventfd_impl (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774 #7 0x0000559d6d9a55c8 in virtio_bus_stop_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259 #8 0x0000559d6d9a53e8 in virtio_bus_grab_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199 #9 0x0000559d6dbf841c in virtio_device_grab_ioeventfd (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783 #10 0x0000559d6d9bde18 in vhost_dev_enable_notifiers (hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592 #11 0x0000559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70, dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266 #12 0x0000559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0, ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412 #13 0x0000559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:311 #14 0x0000559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:392 #15 0x0000559d6dbb60d8 in virtio_net_set_link_status (nc=0x559d7048d890) at ../hw/net/virtio-net.c:455 #16 0x0000559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1", up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459 #17 0x0000559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0, event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301 #18 0x0000559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:62 #19 0x0000559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:82 This issue causes guest kernel stop kicking device and traffic stop. Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong VRING_USED_F_NO_NOTIFY set. Signed-off-by: Yajun Wu <yajunw@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20240402045109.97729-1-yajunw@nvidia.com> [PMD: Use unlikely()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 4c54f5bc8e1d38f15cc35b6a6932d8fbe219c692) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-02hw/intc/arm_gicv3: ICC_HPPIR* return SPURIOUS if int group is disabledPeter Maydell
If the group of the highest priority pending interrupt is disabled via ICC_IGRPEN*, the ICC_HPPIR* registers should return INTID_SPURIOUS, not the interrupt ID. (See the GIC architecture specification pseudocode functions ICC_HPPIR1_EL1[] and HighestPriorityPendingInterrupt().) Make HPPIR reads honour the group disable, the way we already do when determining whether to preempt in icc_hppi_can_preempt(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240328153333.2522667-1-peter.maydell@linaro.org (cherry picked from commit 44e25fbc1900c99c91a44e532c5bd680bc403459) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-31hw/net/net_tx_pkt: Fix virtio header without checksum offloadingAkihiko Odaki
It is incorrect to have the VIRTIO_NET_HDR_F_NEEDS_CSUM set when checksum offloading is disabled so clear the bit. TCP/UDP checksum is usually offloaded when the peer requires virtio headers because they can instruct the peer to compute checksum. However, igb disables TX checksum offloading when a VF is enabled whether the peer requires virtio headers because a transmitted packet can be routed to it and it expects the packet has a proper checksum. Therefore, it is necessary to have a correct virtio header even when checksum offloading is disabled. A real TCP/UDP checksum will be computed and saved in the buffer when checksum offloading is disabled. The virtio specification requires to set the packet checksum stored in the buffer to the TCP/UDP pseudo header when the VIRTIO_NET_HDR_F_NEEDS_CSUM bit is set so the bit must be cleared in that case. Fixes: ffbd2dbd8e64 ("e1000e: Perform software segmentation for loopback") Buglink: https://issues.redhat.com/browse/RHEL-23067 Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 89a8de364b51db8107d2a210314431885ac52238) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-31virtio-net: Fix vhost virtqueue notifiers for RSSAkihiko Odaki
virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask() checked VIRTIO_NET_F_MQ to know there are multiple queues, but VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue, which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is enabled. Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for vhost_vdpa") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 1c188fc8cbffc5f05cc616cab4e1372fb6e6f11f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/kvm: fix timebase-frequency when using KVM accelerationYong-Xuan Wang
The timebase-frequency of guest OS should be the same with host machine. The timebase-frequency value in DTS should be got from hypervisor when using KVM acceleration. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Message-ID: <20240314061510.9800-1-yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix due to missing other changes in this area in 8.2.x)
2024-03-27hw/intc: Update APLIC IDC after claiming iforce registerFrank Chang
Currently, QEMU only sets the iforce register to 0 and returns early when claiming the iforce register. However, this may leave mip.meip remains at 1 if a spurious external interrupt triggered by iforce register is the only pending interrupt to be claimed, and the interrupt cannot be lowered as expected. This commit fixes this issue by calling riscv_aplic_idc_update() to update the IDC status after the iforce register is claimed. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240321104951.12104-1-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 078189b327ae5c5727b51ec714d9663b1d0ca3df) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27hw/scsi/scsi-generic: Fix io_timeout property not applyingLorenz Brun
The io_timeout property, introduced in c9b6609 (part of 6.0) is silently overwritten by the hardcoded default value of 30 seconds (DEFAULT_IO_TIMEOUT) in scsi_generic_realize because that function is being called after the properties have already been applied. The property definition already has a default value which is applied correctly when no value is explicitly set, so we can just remove the code which overrides the io_timeout completely. This has been tested by stracing SG_IO operations with the io_timeout property set and unset and now sets the timeout field in the ioctl request to the proper value. Fixes: c9b6609b69facad ("scsi: make io_timeout configurable") Signed-off-by: Lorenz Brun <lorenz@brun.one> Message-ID: <20240315145831.2531695-1-lorenz@brun.one> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 7c7a9f578e4fb1adff7ac8d9acaaaedb87474e76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27vdpa-dev: Fix initialisation order to restore VDUSE compatibilityKevin Wolf
VDUSE requires that virtqueues are first enabled before the DRIVER_OK status flag is set; with the current API of the kernel module, it is impossible to enable the opposite order in our block export code because userspace is not notified when a virtqueue is enabled. This requirement also mathces the normal initialisation order as done by the generic vhost code in QEMU. However, commit 6c482547 accidentally changed the order for vdpa-dev and broke access to VDUSE devices with this. This changes vdpa-dev to use the normal order again and use the standard vhost callback .vhost_set_vring_enable for this. VDUSE devices can be used with vdpa-dev again after this fix. vhost_net intentionally avoided enabling the vrings for vdpa and does this manually later while it does enable them for other vhost backends. Reflect this in the vhost_net code and return early for vdpa, so that the behaviour doesn't change for this device. Cc: qemu-stable@nongnu.org Fixes: 6c4825476a43 ('vdpa: move vhost_vdpa_set_vring_ready to the caller') Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240315155949.86066-1-kwolf@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 2c66de61f88dc9620a32239f7dd61524a57f66b0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/audio/virtio-sound: return correct command response sizeVolker Rümelin
The payload size returned by command VIRTIO_SND_R_PCM_INFO is wrong. The code in process_cmd() assumes that all commands return only a virtio_snd_hdr payload, but some commands like VIRTIO_SND_R_PCM_INFO may return an additional payload. Add a zero initialized payload_size variable to struct virtio_snd_ctrl_command to allow for additional payloads. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20240218083351.8524-1-vr_qemu@t-online.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 633487df8d303b37a88584d5a57a39dbcd91c7bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hmat acpi: Fix out of bounds access due to missing use of indirectionJonathan Cameron
With a numa set up such as -numa nodeid=0,cpus=0 \ -numa nodeid=1,memdev=mem \ -numa nodeid=2,cpus=1 and appropriate hmat_lb entries the initiator list is correctly computed and writen to HMAT as 0,2 but then the LB data is accessed using the node id (here 2), landing outside the entry_list array. Stash the reverse lookup when writing the initiator list and use it to get the correct array index index. Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240307160326.31570-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 74e2845c5f95b0c139c79233ddb65bb17f2dd679) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13pcie_sriov: Validate NumVFsAkihiko Odaki
The guest may write NumVFs greater than TotalVFs and that can lead to buffer overflow in VF implementations. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26327 Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-2-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> (cherry picked from commit 6081b4243cd64dff1b2cf5b0c215c71e9d7e753b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/nvme: Use pcie_sriov_num_vfs()Akihiko Odaki
nvme_sriov_pre_write_ctrl() used to directly inspect SR-IOV configurations to know the number of VFs being disabled due to SR-IOV configuration writes, but the logic was flawed and resulted in out-of-bound memory access. It assumed PCI_SRIOV_NUM_VF always has the number of currently enabled VFs, but it actually doesn't in the following cases: - PCI_SRIOV_NUM_VF has been set but PCI_SRIOV_CTRL_VFE has never been. - PCI_SRIOV_NUM_VF was written after PCI_SRIOV_CTRL_VFE was set. - VFs were only partially enabled because of realization failure. It is a responsibility of pcie_sriov to interpret SR-IOV configurations and pcie_sriov does it correctly, so use pcie_sriov_num_vfs(), which it provides, to get the number of enabled VFs before and after SR-IOV configuration writes. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26328 Fixes: 11871f53ef8e ("hw/nvme: Add support for the Virtualization Management command") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-1-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 91bb64a8d2014fda33a81fcf0fce37340f0d3b0c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/nvme: add machine compatibility parameter to enable msix exclusive barKlaus Jensen
Commit 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") moved the MSI-X table and PBA to BAR 0 to make room for enabling CMR and PMR at the same time. As reported by Julien Grall in #2184, this breaks migration through system hibernation. Add a machine compatibility parameter and set it on machines pre 6.0 to enable the old behavior automatically, restoring the hibernation migration support. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2184 Fixes: 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") Reported-by: Julien Grall julien@xen.org Tested-by: Julien Grall julien@xen.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit fa905f65c5549703279f68c253914799b10ada47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/nvme: generalize the mbar size helperKlaus Jensen
Generalize the mbar size helper such that it can handle cases where the MSI-X table and PBA are expected to be in an exclusive bar. Cc: qemu-stable@nongnu.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit ee7bda4d38cda3eaf114c850a723dd12e23d3abc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/nvme: fix invalid check on mclKlaus Jensen
The number of logical blocks within a source range is converted into a 1s based number at the time of parsing. However, when verifying the copy length we add one again, causing the check against MCL to fail in error. Cc: qemu-stable@nongnu.org Fixes: 381ab99d8587 ("hw/nvme: check maximum copy length (MCL) for COPY") Reviewed-by: Minwoo Im <minwoo.im@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 8c78015a55d84c016da6d5e41b6b5f618ecb25ab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13hw/nvme: separate 'serial' property for VFsMinwoo Im
Currently, when a VF is created, it uses the 'params' object of the PF as it is. In other words, the 'params.serial' string memory area is also shared. In this situation, if the VF is removed from the system, the PF's 'params.serial' object is released with object_finalize() followed by object_property_del_all() which release the memory for 'serial' property. If that happens, the next VF created will inherit a serial from a corrupted memory area. If this happens, an error will occur when comparing subsys->serial and n->params.serial in the nvme_subsys_register_ctrl() function. Cc: qemu-stable@nongnu.org Fixes: 44c2c09488db ("hw/nvme: Add support for SR-IOV") Signed-off-by: Minwoo Im <minwoo.im@samsung.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 4f0a4a3d5854824e5c5eccf353d4a1f4f749a29d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-13xen: Drop out of coroutine context xen_invalidate_map_cache_entryPeng Fan
xen_invalidate_map_cache_entry is not expected to run in a coroutine. Without this, there is crash: signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 threadid=<optimized out>) at pthread_kill.c:78 at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/raise.c:26 fmt=0xffff9e1ca8a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xaaaae0d25740 "!qemu_in_coroutine()", file=file@entry=0xaaaae0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xaaaae0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:92 assertion=assertion@entry=0xaaaae0d25740 "!qemu_in_coroutine()", file=file@entry=0xaaaae0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xaaaae0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:101 at ../qemu-xen-dir-remote/block/graph-lock.c:260 at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/block/graph-lock.h:259 host=host@entry=0xffff742c8000, size=size@entry=2097152) at ../qemu-xen-dir-remote/block/io.c:3362 host=0xffff742c8000, size=2097152) at ../qemu-xen-dir-remote/block/block-backend.c:2859 host=<optimized out>, size=<optimized out>, max_size=<optimized out>) at ../qemu-xen-dir-remote/block/block-ram-registrar.c:33 size=2097152, max_size=2097152) at ../qemu-xen-dir-remote/hw/core/numa.c:883 buffer=buffer@entry=0xffff743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:475 buffer=buffer@entry=0xffff743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:487 as=as@entry=0xaaaae1ca3ae8 <address_space_memory>, buffer=0xffff743c5000, len=<optimized out>, is_write=is_write@entry=true, access_len=access_len@entry=32768) at ../qemu-xen-dir-remote/system/physmem.c:3199 dir=DMA_DIRECTION_FROM_DEVICE, len=<optimized out>, buffer=<optimized out>, as=0xaaaae1ca3ae8 <address_space_memory>) at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/sysemu/dma.h:236 elem=elem@entry=0xaaaaf620aa30, len=len@entry=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:758 elem=elem@entry=0xaaaaf620aa30, len=len@entry=32769, idx=idx@entry=0) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:919 elem=elem@entry=0xaaaaf620aa30, len=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:994 req=req@entry=0xaaaaf620aa30, status=status@entry=0 '\000') at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:67 ret=0) at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:136 at ../qemu-xen-dir-remote/block/block-backend.c:1559 --Type <RET> for more, q to quit, c to continue without paging-- at ../qemu-xen-dir-remote/block/block-backend.c:1614 i1=<optimized out>) at ../qemu-xen-dir-remote/util/coroutine-ucontext.c:177 at ../sysdeps/unix/sysv/linux/aarch64/setcontext.S:123 Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <20240124021450.21656-1-peng.fan@oss.nxp.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> (cherry picked from commit 9253d83062268209533df4b29859e5b51a2dc324) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-08 01:37:04 +0000