aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2024-03-01hw/usb/bus.c: PCAP adding 0xA in Windows versionBenjamin David Lunt1-2/+3
Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. This is due to the fact that the PCAP file is opened as TEXT instead of BINARY. To show an example, when using a very common protocol to USB disks, the BBB protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10) command will have a command block length of 10 (0xA). When this 10-byte command (part of the 31-byte CBW) is placed into the PCAP file, the Windows file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a 32-byte CBW. Actual CBW: 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC...........% 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... PCAP CBW 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............ 0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. I believe simply opening the PCAP file as BINARY instead of TEXT will fix this issue. Resolves: https://bugs.launchpad.net/qemu/+bug/2054889 Signed-off-by: Benjamin David Lunt <benlunt@fysnet.net> Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net> [thuth: Break long line to avoid checkpatch.pl error] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 5e02a4fdebc442e34c5bb05e4540f85cc6e802f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-01hw/intc/Kconfig: Fix GIC settings when using "--without-default-devices"Thomas Huth1-6/+6
When using "--without-default-devices", the ARM_GICV3_TCG and ARM_GIC_KVM settings currently get disabled, though the arm virt machine is only of very limited use in that case. This also causes the migration-test to fail in such builds. Let's make sure that we always keep the GIC switches enabled in the --without-default-devices builds, too. Message-ID: <20240221110059.152665-1-thuth@redhat.com> Tested-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8bd3f84d1f6fba0edebc450be6fa2c7630584df9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-27pl031: Update last RTCLR value on write in case it's read backJessica Clarke1-0/+1
The PL031 allows you to read RTCLR, which is meant to give you the last value written. PL031State has an lr field which is used when reading from RTCLR, and is present in the VM migration state, but we never actually update it, so it always reads as its initial 0 value. Cc: qemu-stable@nongnu.org Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240222000341.1562443-1-jrtc27@jrtc27.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4d28d57c9f2eb1cdf70b29cea6e50282e010075b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-27hw/nvme: fix invalid endian conversionKlaus Jensen1-1/+1
numcntl is one byte and so is max_vfs. Using cpu_to_le16 on big endian hosts results in numcntl being set to 0. Fix by dropping the endian conversion. Fixes: 99f48ae7ae ("hw/nvme: Add support for Secondary Controller List") Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Minwoo Im <minwoo.im@samsung.com> Message-ID: <20240222-fix-sriov-numcntl-v1-1-d60bea5e72d0@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit d2b5bb860e6c17442ad95cc275feb07c1665be5c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-22hw/hppa/Kconfig: Fix building with "configure --without-default-devices"Thomas Huth1-0/+2
When running "configure" with "--without-default-devices", building of qemu-system-hppa currently fails with: /usr/bin/ld: libqemu-hppa-softmmu.fa.p/hw_hppa_machine.c.o: in function `machine_HP_common_init_tail': hw/hppa/machine.c:399: undefined reference to `usb_bus_find' /usr/bin/ld: hw/hppa/machine.c:399: undefined reference to `usb_create_simple' /usr/bin/ld: hw/hppa/machine.c:400: undefined reference to `usb_bus_find' /usr/bin/ld: hw/hppa/machine.c:400: undefined reference to `usb_create_simple' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. make: *** [Makefile:162: run-ninja] Error 1 And after fixing this, the qemu-system-hppa binary refuses to run due to the missing 'pci-ohci' and 'pci-serial' devices. Let's add the right config switches to fix these problems. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 04b86ccb5dc8a1fad809753cfbaafd4bb13283d4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-15hw/i386: Fix _STA return value for ACPI0017Jonathan Cameron1-1/+1
Found whilst testing a series for the linux kernel that actually bothers to check if enabled is set. 0xB is the option used for vast majority of DSDT entries in QEMU. It is a little odd for a device that doesn't really exist and is simply a hook to tell the OS there is a CEDT table but 0xB seems a reasonable choice and avoids need to special case this device in the OS. Means: * Device present. * Device enabled and decoding it's resources. * Not shown in UI * Functioning properly * No battery (on this device!) Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240126120132.24248-12-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 d9ae5802f656f6fb53b788747ba557a826b6e740) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-15smmu: Clear SMMUPciBus pointer cache when system resetZhenzhong Duan1-0/+2
s->smmu_pcibus_by_bus_num is a SMMUPciBus pointer cache indexed by bus number, bus number may not always be a fixed value, i.e., guest reboot to different kernel which set bus number with different algorithm. This could lead to smmu_iommu_mr() providing the wrong iommu MR. Suggested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20240125073706.339369-3-zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 8a6b3f4dc95a064e88adaca86374108da0ecb38d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-15virtio_iommu: Clear IOMMUPciBus pointer cache when system resetZhenzhong Duan1-2/+2
s->iommu_pcibus_by_bus_num is a IOMMUPciBus pointer cache indexed by bus number, bus number may not always be a fixed value, i.e., guest reboot to different kernel which set bus number with different algorithm. This could lead to endpoint binding to wrong iommu MR in virtio_iommu_get_endpoint(), then vfio device setup wrong mapping from other device. Remove the memset in virtio_iommu_device_realize() to avoid redundancy with memset in system reset. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20240125073706.339369-2-zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9a457383ce9d309d4679b079fafb51f0a2d949aa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14virtio-gpu: Correct virgl_renderer_resource_get_info() error checkDmitry Osipenko1-1/+1
virgl_renderer_resource_get_info() returns errno and not -1 on error. Correct the return-value check. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Message-Id: <20240129073921.446869-1-dmitry.osipenko@collabora.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 574b64aa6754ba491f51024c5a823a674d48a658) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14hw/cxl: Pass CXLComponentState to cache_mem_opsLi Zhijian1-1/+1
cache_mem_ops.{read,write}() interprets opaque as CXLComponentState(cxl_cstate) instead of ComponentRegisters(cregs). Fortunately, cregs is the first member of cxl_cstate, so their values are the same. Fixes: 9e58f52d3f8 ("hw/cxl/component: Introduce CXL components (8.1.x, 8.2.5)") Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240126120132.24248-8-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 729d45a6af06753d3e330f589c248fe9687c5cd5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14hw/cxl/device: read from register values in mdev_reg_read()Hyeonggon Yoo1-6/+11
In the current mdev_reg_read() implementation, it consistently returns that the Media Status is Ready (01b). This was fine until commit 25a52959f99d ("hw/cxl: Add support for device sanitation") because the media was presumed to be ready. However, as per the CXL 3.0 spec "8.2.9.8.5.1 Sanitize (Opcode 4400h)", during sanitation, the Media State should be set to Disabled (11b). The mentioned commit correctly sets it to Disabled, but mdev_reg_read() still returns Media Status as Ready. To address this, update mdev_reg_read() to read register values instead of returning dummy values. Note that __toggle_media() managed to not only write something that no one read, it did it to the wrong register storage and so changed the reported mailbox size which was definitely not the intent. That gets fixed as a side effect of allocating separate state storage for this register. Fixes: commit 25a52959f99d ("hw/cxl: Add support for device sanitation") Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240126120132.24248-7-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 f7509f462c788a347521f90f19d623908c4fbcc5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14cxl/cdat: Fix header sum value in CDAT checksumIra Weiny1-2/+7
The addition of the DCD support for CXL type-3 devices extended the CDAT table large enough that the checksum being returned was incorrect.[1] This was because the checksum value was using the header length field rather than each of the 4 bytes of the length field. This was previously not seen because the length of the CDAT data was less than 256 thus resulting in an equivalent checksum value. Properly calculate the checksum for the CDAT header. [1] https://lore.kernel.org/all/20231116-fix-cdat-devm-free-v1-1-b148b40707d7@intel.com/ Fixes: aba578bdace5 ("hw/cxl/cdat: CXL CDAT Data Object Exchange implementation") Cc: Huai-Cheng Kuo <hchkuo@avery-design.com.tw> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240126120132.24248-5-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 64fdad5e67587e88c2f1d8f294e89403856a4a31) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14cxl/cdat: Handle cdat table build errorsIra Weiny1-1/+1
The callback for building CDAT tables may return negative error codes. This was previously unhandled and will result in potentially huge allocations later on in ct3_build_cdat() Detect the negative error code and defer cdat building. Fixes: f5ee7413d592 ("hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange") Cc: Huai-Cheng Kuo <hchkuo@avery-design.com.tw> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240126120132.24248-2-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 c62926f730d08450502d36548e28dd727c998ace) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-14hw/net/tulip: add chip status register valuesSven Schnelle1-2/+2
Netbsd isn't able to detect a link on the emulated tulip card. That's because netbsd reads the Chip Status Register of the Phy (address 0x14). The default phy data in the qemu tulip driver is all zero, which means no link is established and autonegotation isn't complete. Therefore set the register to 0x3b40, which means: Link is up, Autonegotation complete, Full Duplex, 100MBit/s Link speed. Also clear the mask because this register is read only. Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Helge Deller <deller@gmx.de> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 9b60a3ed5569a70bbdd29e3c9ec4c5d4685c6e2c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-13hw/smbios: Fix port connector option validationAkihiko Odaki1-0/+6
qemu_smbios_type8_opts did not have the list terminator and that resulted in out-of-bound memory access. It also needs to have an element for the type option. Cc: qemu-stable@nongnu.org Fixes: fd8caa253c56 ("hw/smbios: support for type 8 (port connector)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 196578c9d051d19c23e6c13e97b791a41b318315)
2024-02-13hw/smbios: Fix OEM strings table option validationAkihiko Odaki1-0/+6
qemu_smbios_type11_opts did not have the list terminator and that resulted in out-of-bound memory access. It also needs to have an element for the type option. Cc: qemu-stable@nongnu.org Fixes: 2d6dcbf93fb0 ("smbios: support setting OEM strings table") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit cd8a35b913c24248267c682cb9a348461c106139)
2024-02-13hw/riscv/virt-acpi-build.c: fix leak in build_rhct()Daniel Henrique Barboza1-1/+1
The 'isa' char pointer isn't being freed after use. Issue detected by Valgrind: ==38752== 128 bytes in 1 blocks are definitely lost in loss record 3,190 of 3,884 ==38752== at 0x484280F: malloc (vg_replace_malloc.c:442) ==38752== by 0x5189619: g_malloc (gmem.c:130) ==38752== by 0x51A5BF2: g_strconcat (gstrfuncs.c:628) ==38752== by 0x6C1E3E: riscv_isa_string_ext (cpu.c:2321) ==38752== by 0x6C1E3E: riscv_isa_string (cpu.c:2343) ==38752== by 0x6BD2EA: build_rhct (virt-acpi-build.c:232) ==38752== by 0x6BD2EA: virt_acpi_build (virt-acpi-build.c:556) ==38752== by 0x6BDC86: virt_acpi_setup (virt-acpi-build.c:662) ==38752== by 0x9C8DC6: notifier_list_notify (notify.c:39) ==38752== by 0x4A595A: qdev_machine_creation_done (machine.c:1589) ==38752== by 0x61E052: qemu_machine_creation_done (vl.c:2680) ==38752== by 0x61E052: qmp_x_exit_preconfig.part.0 (vl.c:2709) ==38752== by 0x6220C6: qmp_x_exit_preconfig (vl.c:2702) ==38752== by 0x6220C6: qemu_init (vl.c:3758) ==38752== by 0x425858: main (main.c:47) Fixes: ebfd392893 ("hw/riscv/virt: virt-acpi-build.c: Add RHCT Table") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122221529.86562-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 1a49762c07d001ce291e4fc6773317f5611af3a4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup)
2024-02-12virtio-blk: avoid using ioeventfd state in irqfd conditionalStefan Hajnoczi1-1/+1
Requests that complete in an IOThread use irqfd to notify the guest while requests that complete in the main loop thread use the traditional qdev irq code path. The reason for this conditional is that the irq code path requires the BQL: if (s->ioeventfd_started && !s->ioeventfd_disabled) { virtio_notify_irqfd(vdev, req->vq); } else { virtio_notify(vdev, req->vq); } There is a corner case where the conditional invokes the irq code path instead of the irqfd code path: static void virtio_blk_stop_ioeventfd(VirtIODevice *vdev) { ... /* * Set ->ioeventfd_started to false before draining so that host notifiers * are not detached/attached anymore. */ s->ioeventfd_started = false; /* Wait for virtio_blk_dma_restart_bh() and in flight I/O to complete */ blk_drain(s->conf.conf.blk); During blk_drain() the conditional produces the wrong result because ioeventfd_started is false. Use qemu_in_iothread() instead of checking the ioeventfd state. Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-15394 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240122172625.415386-1-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit bfa36802d1704fc413c590ebdcc4e5ae0eacf439) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup for v8.2.0-809-g3cdaf3dd4a "virtio-blk: rename dataplane to ioeventfd")
2024-02-12virtio: Re-enable notifications after drainHanna Czenczek1-0/+42
During drain, we do not care about virtqueue notifications, which is why we remove the handlers on it. When removing those handlers, whether vq notifications are enabled or not depends on whether we were in polling mode or not; if not, they are enabled (by default); if so, they have been disabled by the io_poll_start callback. Because we do not care about those notifications after removing the handlers, this is fine. However, we have to explicitly ensure they are enabled when re-attaching the handlers, so we will resume receiving notifications. We do this in virtio_queue_aio_attach_host_notifier*(). If such a function is called while we are in a polling section, attaching the notifiers will then invoke the io_poll_start callback, re-disabling notifications. Because we will always miss virtqueue updates in the drained section, we also need to poll the virtqueue once after attaching the notifiers. Buglink: https://issues.redhat.com/browse/RHEL-3934 Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20240202153158.788922-3-hreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 5bdbaebcce18fe6a627cafad2043ec08f3de5744) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-12virtio-scsi: Attach event vq notifier with no_pollHanna Czenczek1-1/+6
As of commit 38738f7dbbda90fbc161757b7f4be35b52205552 ("virtio-scsi: don't waste CPU polling the event virtqueue"), we only attach an io_read notifier for the virtio-scsi event virtqueue instead, and no polling notifiers. During operation, the event virtqueue is typically non-empty, but none of the buffers are intended to be used immediately. Instead, they only get used when certain events occur. Therefore, it makes no sense to continuously poll it when non-empty, because it is supposed to be and stay non-empty. We do this by using virtio_queue_aio_attach_host_notifier_no_poll() instead of virtio_queue_aio_attach_host_notifier() for the event virtqueue. Commit 766aa2de0f29b657148e04599320d771c36fd126 ("virtio-scsi: implement BlockDevOps->drained_begin()") however has virtio_scsi_drained_end() use virtio_queue_aio_attach_host_notifier() for all virtqueues, including the event virtqueue. This can lead to it being polled again, undoing the benefit of commit 38738f7dbbda90fbc161757b7f4be35b52205552. Fix it by using virtio_queue_aio_attach_host_notifier_no_poll() for the event virtqueue. Reported-by: Fiona Ebner <f.ebner@proxmox.com> Fixes: 766aa2de0f29b657148e04599320d771c36fd126 ("virtio-scsi: implement BlockDevOps->drained_begin()") Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-ID: <20240202153158.788922-2-hreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit c42c3833e0cfdf2b80fb3ca410acfd392b6874ab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-09hw/scsi/lsi53c895a: add missing decrement of reentrancy counterSven Schnelle1-0/+1
When the maximum count of SCRIPTS instructions is reached, the code stops execution and returns, but fails to decrement the reentrancy counter. This effectively renders the SCSI controller unusable because on next entry the reentrancy counter is still above the limit. This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS loops. Fixes: b987718bbb ("hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330)") Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-ID: <20240128202214.2644768-1-svens@stackframe.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8b09b7fe47082c69295a0fc0cc01b041b6385025) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-09pci-host: designware: Limit value range of iATU viewport registerGuenter Roeck1-0/+2
The latest version of qemu (v8.2.0-869-g7a1dc45af5) crashes when booting the mcimx7d-sabre emulation with Linux v5.11 and later. qemu-system-arm: ../system/memory.c:2750: memory_region_set_alias_offset: Assertion `mr->alias' failed. Problem is that the Designware PCIe emulation accepts the full value range for the iATU Viewport Register. However, both hardware and emulation only support four inbound and four outbound viewports. The Linux kernel determines the number of supported viewports by writing 0xff into the viewport register and reading the value back. The expected value when reading the register is the highest supported viewport index. Match that code by masking the supported viewport value range when the register is written. With this change, the Linux kernel reports imx6q-pcie 33800000.pcie: iATU: unroll F, 4 ob, 4 ib, align 0K, limit 4G as expected and supported. Fixes: d64e5eabc4c7 ("pci: Add support for Designware IP block") Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Nikita Ostrenkov <n.ostrenkov@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20240129060055.2616989-1-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 8a73152020337a7fbf34daf0a006d4d89ec1494e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-29vfio/pci: Clear MSI-X IRQ index alwaysCédric Le Goater1-3/+5
When doing device assignment of a physical device, MSI-X can be enabled with no vectors enabled and this sets the IRQ index to VFIO_PCI_MSIX_IRQ_INDEX. However, when MSI-X is disabled, the IRQ index is left untouched if no vectors are in use. Then, when INTx is enabled, the IRQ index value is considered incompatible (set to MSI-X) and VFIO_DEVICE_SET_IRQS fails. QEMU complains with : qemu-system-x86_64: vfio 0000:08:00.0: Failed to set up TRIGGER eventfd signaling for interrupt INTX-0: VFIO_DEVICE_SET_IRQS failure: Invalid argument To avoid that, unconditionaly clear the IRQ index when MSI-X is disabled. Buglink: https://issues.redhat.com/browse/RHEL-21293 Fixes: 5ebffa4e87e7 ("vfio/pci: use an invalid fd to enable MSI-X") Cc: Jing Liu <jing2.liu@intel.com> Cc: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> (cherry picked from commit d2b668fca5652760b435ce812a743bba03d2f316) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-26virtio-net: correctly copy vnet header when flushing TXJason Wang1-4/+9
When HASH_REPORT is negotiated, the guest_hdr_len might be larger than the size of the mergeable rx buffer header. Using virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack overflow in this case. Fixing this by using virtio_net_hdr_v1_hash instead. Reported-by: Xiao Lei <leixiao.nop@zju.edu.cn> Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: qemu-stable@nongnu.org Cc: Mauro Matteo Cascella <mcascell@redhat.com> Fixes: CVE-2023-6693 Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: drive ISM reset from subsystem resetMatthew Rosato2-9/+25
ISM devices are sensitive to manipulation of the IOMMU, so the ISM device needs to be reset before the vfio-pci device is reset (triggering a full UNMAP). In order to ensure this occurs, trigger ISM device resets from subsystem_reset before triggering the PCI bus reset (which will also trigger vfio-pci reset). This only needs to be done for ISM devices which were enabled for use by the guest. Further, ensure that AIF is disabled as part of the reset event. Fixes: ef1535901a ("s390x: do a subsystem reset before the unprotect on reboot") Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-4-mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 68c691ca99a2538d6a53a70ce8a9ce06ee307ff1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: refresh fh before disabling aifMatthew Rosato1-0/+9
Typically we refresh the host fh during CLP enable, however it's possible that the device goes through multiple reset events before the guest performs another CLP enable. Let's handle this for now by refreshing the host handle from vfio before disabling aif. Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-3-mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 30e35258e25c75c9d799c34fd89afcafffb37084) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-22s390x/pci: avoid double enable/disable of aifMatthew Rosato1-2/+23
Use a flag to keep track of whether AIF is currently enabled. This can be used to avoid enabling/disabling AIF multiple times as well as to determine whether or not it should be disabled during reset processing. Fixes: d0bc7091c2 ("s390x/pci: enable adapter event notification for interpreted devices") Reported-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-2-mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 07b2c8e034d80ff92e202405c494d2ff80fcf848) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issuedMark Cave-Ayland1-0/+1
Even though the BLAST command isn't fully implemented in QEMU, the DMA_STAT_BCMBLT bit should be set after the command has been issued to indicate that the command has completed. This fixes an issue with the DC390 DOS driver which issues the BLAST command as part of its normal error recovery routine at startup, and otherwise sits in a tight loop waiting for DMA_STAT_BCMBLT to be set before continuing. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion ↵Mark Cave-Ayland1-15/+13
interrupt The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to generate an interrupt, however the Linux driver manually checks for DMA_STAT_DONE being set and if it is, considers that a DMA transfer has completed. If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then the Linux driver considers this to be a spurious interrupt. However this can occur in QEMU as there is a delay between the end of DMA transfer where DMA_STAT_DONE is set, and the ESP device raising its completion interrupt. This appears to be an incorrect assumption in the Linux driver as the ESP and PCI DMA interrupt sources are separate (and may not be raised exactly together), however we can work around this by synchronising the setting of DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt. In conjunction with the previous commit Linux is now able to correctly boot from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting "iget: checksum invalid" and "Spurious irq, sreg=10" errors. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sourcesMark Cave-Ayland1-5/+27
The am53c974/dc390 PCI interrupt has two separate sources: the first is from the internal ESP device, and the second is from the PCI DMA transfer logic. Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function to generate the correct PCI IRQ level. In particular this fixes spurious interrupts being generated by setting DMA_STAT_DONE at the end of a transfer if DMA_CMD_INTE_D isn't set in the DMA_CMD register. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/scsi/esp-pci: use correct address register for PCI DMA transfersMark Cave-Ayland1-1/+1
The current code in esp_pci_dma_memory_rw() sets the DMA address to the value of the DMA_SPA (Starting Physical Address) register which is incorrect: this means that for each callback from the SCSI layer the DMA address is set back to the starting address. In the case where only a single SCSI callback occurs (currently for transfer lengths < 128kB) this works fine, however for larger transfers the DMA address wraps back to the initial starting address, corrupting the buffer holding the data transferred to the guest. Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for the DMA address which is correctly incremented across multiple SCSI layer transfers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/pflash: implement update buffer for block writesGerd Hoffmann3-30/+89
Add an update buffer where all block updates are staged. Flush or discard updates properly, so we should never see half-completed block writes in pflash storage. Drop a bunch of FIXME comments ;) Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-4-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop const in hw/block/pflash_cfi01.c for before v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState")
2024-01-20hw/pflash: use ldn_{be,le}_p and stn_{be,le}_pGerd Hoffmann1-55/+8
Use the helper functions we have to read/write multi-byte values in correct byte order. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-3-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-20hw/pflash: refactor pflash_data_write()Gerd Hoffmann1-14/+16
Move the offset calculation, do it once at the start of the function and let the 'p' variable point directly to the memory location which should be updated. This makes it simpler to update other buffers than pfl->storage in an upcoming patch. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-2-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa: Move software power button address back into PDCHelge Deller1-4/+5
The various operating systems (e.g. Linux, NetBSD) have issues mapping the power button when it's stored in page zero. NetBSD even crashes, because it fails to map that page and then accesses unmapped memory. Since we now have a consistent memory mapping of PDC in 32-bit and 64-bit address space (the lower 32-bits of the address are in sync) the power button can be moved back to PDC space. This patch fixes the power button on Linux, NetBSD and HP-UX. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Bruno Haible <bruno@clisp.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ed35afcb331a972210816435d6b1b5de17fc7d4f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/pci-host/astro: Add missing astro & elroy registers for NetBSDHelge Deller1-3/+23
NetBSD accesses some astro and elroy registers which aren't accessed by Linux yet. Add emulation for those registers to allow NetBSD to boot further. Please note that this patch is not sufficient to completely boot up NetBSD on the 64-bit C3700 machine yet. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 3b57c15f02050227c5c73ca97fa0dfc02f154fe9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa/machine: Disable default devices with --nodefaults optionHelge Deller1-4/+6
Recognize the qemu --nodefaults option, which will disable the following default devices on hppa: - lsi53c895a SCSI controller, - artist graphics card, - LASI 82596 NIC, - tulip PCI NIC, - second serial PCI card, - USB OHCI controller. Adding this option is very useful to allow manual testing and debugging of the other possible devices on the command line. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit d8a3220005d74512677b181e3a32cd94b13ddf49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-17hw/hppa/machine: Allow up to 3840 MB total memoryHelge Deller1-3/+6
The physical hardware allows DIMMs of 4 MB size and above, allowing up to 3840 MB of memory, but is restricted by setup code to 3 GB. Increase the limit to allow up to the maximum amount of memory. Btw. the memory area from 0xf000.0000 to 0xffff.ffff is reserved by the architecture for firmware and I/O memory and can not be used for standard memory. An upcoming 64-bit SeaBIOS-hppa firmware will allow more than 3.75GB on 64-bit HPPA64. In this case the ram_max for the pa20 case will change. Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: Nelson H. F. Beebe <beebe@math.utah.edu> Fixes: b7746b1194c8 ("hw/hppa/machine: Restrict the total memory size to 3GB") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Bruno Haible <bruno@clisp.org> (cherry picked from commit 92039f61af89629f268e04255946c2a3fa0c453f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-11hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registersPeter Maydell1-4/+13
The hypervisor can deliver (virtual) LPIs to a guest by setting up a list register to have an intid which is an LPI. The GIC has to treat these a little differently to standard interrupt IDs, because LPIs have no Active state, and so the guest will only EOI them, it will not also deactivate them. So icv_eoir_write() must do two things: * if the LPI ID is not in any list register, we drop the priority but do not increment the EOI count * if the LPI ID is in a list register, we immediately deactivate it, regardless of the split-drop-and-deactivate control This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1() pseudocode in the GICv3 architecture specification. Without this fix, potentially a hypervisor guest might stall because LPIs get stuck in a bogus Active+Pending state. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com> (cherry picked from commit 82a65e3188abebb509510b391726711606aca642) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-08hw/vfio: fix iteration over global VFIODevice listVolker Rümelin1-4/+4
Commit 3d779abafe ("vfio/common: Introduce a global VFIODevice list") introduced a global VFIODevice list, but forgot to update the list element field name when iterating over the new list. Change the code to use the correct list element field. Fixes: 3d779abafe ("vfio/common: Introduce a global VFIODevice list") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2061 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> (cherry picked from commit 9353b6da430f90e47f352dbf6dc31120c8914da6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-08vfio/container: Replace basename with g_path_get_basenameCédric Le Goater1-2/+3
g_path_get_basename() is a portable utility function that has the advantage of not modifing the string argument. It also fixes a compile breakage with the Musl C library reported in [1]. [1] https://lore.kernel.org/all/20231212010228.2701544-1-raj.khem@gmail.com/ Reported-by: Khem Raj <raj.khem@gmail.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> (cherry picked from commit 213ae3ffda463c0503e39e0cf827511b5298c314) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-08edu: fix DMA range upper bound checkMax Erenberg1-1/+1
The edu_check_range function checks that start <= end1 < end2, where end1 is the upper bound (exclusive) of the guest-supplied DMA range and end2 is the upper bound (exclusive) of the device's allowed DMA range. When the guest tries to transfer exactly DMA_SIZE (4096) bytes, end1 will be equal to end2, so the check fails and QEMU aborts with this puzzling error message (newlines added for formatting): qemu: hardware error: EDU: DMA range 0x0000000000040000-0x0000000000040fff out of bounds (0x0000000000040000-0x0000000000040fff)! By checking end1 <= end2 instead, guests will be allowed to transfer exactly 4096 bytes. It is not necessary to explicitly check for start <= end1 because the previous two checks (within(addr, start, end2) and end1 > addr) imply start < end1. Fixes: b30934cb52a7 ("hw: misc, add educational driver", 2015-01-21) Signed-off-by: Max Erenberg <merenber@uwaterloo.ca> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 2c5107e1b455d4a157124f021826ead4e04b4aea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-08hw/net: cadence_gem: Fix MDIO_OP_xxx valuesBin Meng1-2/+2
Testing upstream U-Boot with 'sifive_u' machine we see: => dhcp ethernet@10090000: PHY present at 0 Could not get PHY for ethernet@10090000: addr 0 phy_connect failed This has been working till QEMU 8.1 but broken since QEMU 8.2. Fixes: 1b09eeb122aa ("hw/net/cadence_gem: use FIELD to describe PHYMNTNC register fields") Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 0c7ffc977195c1f71c8132eb5616827e589d4a0f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-05hw/net/can/sja1000: fix bug for single acceptance filter and standard framePavel Pisa1-1/+1
A CAN sja1000 standard frame filter mask has been computed and applied incorrectly for standard frames when single Acceptance Filter Mode (MOD_AFM = 1) has been selected. The problem has not been found by Linux kernel testing because it uses dual filter mode (MOD_AFM = 0) and leaves falters fully open. The problem has been noticed by Grant Ramsay when testing with Zephyr RTOS which uses single filter mode. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Reported-by: Grant Ramsay <gramsay@enphaseenergy.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2028 Fixes: 733210e754 ("hw/net/can: SJA1000 chip register level emulation") Message-ID: <20240103231426.5685-1-pisa@fel.cvut.cz> (cherry picked from commit 25145a7d7735344a469551946fc2a7f19eb4aa3d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-05target/i386: the sgx_epc_get_section stub is reachablePaolo Bonzini1-1/+1
The sgx_epc_get_section stub is reachable from cpu_x86_cpuid. It should not assert, instead it should just return true just like the "real" sgx_epc_get_section does when SGX is disabled. Reported-by: Vladimír Beneš <vbenes@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20220201190941.106001-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 219615740425d9683588207b40a365e6741691a6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-05hw/ufs: avoid generating the same ID string for different LU devicesAkinobu Mita1-0/+8
QEMU would not start when trying to create two UFS host controllers and a UFS logical unit for each with the following options: -device ufs,id=bus0 \ -device ufs-lu,drive=drive1,bus=bus0,lun=0 \ -device ufs,id=bus1 \ -device ufs-lu,drive=drive2,bus=bus1,lun=0 \ This is because the same ID string ("0:0:0/scsi-disk") is generated for both UFS logical units. To fix this issue, prepend the parent pci device's path to make the ID string unique. ("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk") Resolves: #2018 Fixes: 096434fea13a ("hw/ufs: Modify lu.c to share codes with SCSI subsystem") Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Reviewed-by: Jeuk Kim <jeuk20.kim@samsung.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231204150543.48252-1-akinobu.mita@gmail.com> Signed-off-by: Jeuk Kim <jeuk20.kim@samsung.com>
2023-12-04Merge tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu into ↵Stefan Hajnoczi1-0/+1
staging ui/audio fixes for 8.2 # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmVtiO0cHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5UDeEACvbixo8MuxOpBf9DK2 # JTCQeHYeVW7QtwDh9xUUnbcM77+lWgkr9OeCJ7FKxF1J7UHkQ7jIzISs/P0zuCw0 # JRkoOcfOnxV/Pn8XAq79F6Yq55EUdCdvsj0XgsVx+K096VHvjlK3fzNwNebJrkos # NpwQnnqI37TYBUFSivjKkEkPf1Kp4R4abeNs3eEzsIMUzEmEZQwwi5zZAMxxZ41o # fyItvdaEEDJxzupS6e0x4O4B5KkTo9RFwsJgstOAbkCxuJk67grV9dm3S3wFiUR3 # iFR2P/EyzctT9QOkU7oEIi87CiociKaYWgw/tDU4lFjXwbkt0a59b783Rha1RlN8 # ICFQ3B0NX+CNlc5PPsF1yp3+DNJRKz8Rap4PmU5IIVXTlPHm+YrWRw6vklw5kq7y # nAvdcfIJ+UQGVCgqQiLkuZslz4ATFOypnUvSL+eds1jHMS6UQcGd3zD1QCEPhDSP # jhFirqDQYWU/18ZU3b6VuDe5Ko3erd4V7hDikeQnjLjYfBFX1/Mts+6GmaGdfbqk # JLOHYa7CUP7akTB7fQF1/4B6cSf3hOsXYlmDHQPZgi1OYEy/BdPuwM5pN4jAikwO # b2z6TrXS3hQK61bUtU+XnhOOW98+gfz77UwluXDl22KHGV+c/SadyMFJWm8VYX4k # DuNTQ78vApqCuAhjFcKSXPSt7A== # =fpz/ # -----END PGP SIGNATURE----- # gpg: Signature made Mon 04 Dec 2023 03:08:13 EST # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu: hw/audio/virtio-sound: mark the device as unmigratable ui/vnc-clipboard: fix inflate_buffer ui/gtk-egl: move function calls back to regular code path Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-12-04Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Stefan Hajnoczi12-47/+101
into staging virtio,pc,pci: features, cleanups, fixes misc fixes, cleanups Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmVrmhwPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp/XsH/05hHtQqO+EnKSAW5SEwZnlLfzDcajVVPIkT # h6Yf6ahHNf4hG1qqa2CICqJtDAOQYamO128QjZdQxsnYejwBmZ/oG//neWh6qLPV # Hp4AaKV2MjKRQZPNblnrGUirxkSWSTqIONXp4FsVVpKOKW9IX5f9tH6nyFAqXWX7 # KzNY/3KD1CVSwAV1+hY2c6OzWVdTSJykPRocfB0jTYY1RygI0t57Hiq7v8AliGAx # 7ktSJFD9MBr+4Un7CQZWp24eyrL77j8U+YQRlPVYupkmQyuXHPdBr4RruHcGupIy # GeIvbkX1mTCEfOd/HFQ1X41hpf8AEyZjjq2SOEBncIRWY6EhSio= # =opjy # -----END PGP SIGNATURE----- # gpg: Signature made Sat 02 Dec 2023 15:57:00 EST # 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: vhost-user-scsi: free the inflight area when reset vhost-user: fix the reconnect error msix: unset PCIDevice::msix_vector_poll_notifier in rollback virtio-iommu: Remove useless !sdev check in virtio_iommu_probe() hw/i386: fix short-circuit logic with non-optimizing builds hw/acpi/erst: Do not ignore Error* in realize handler pcie_sriov: Remove g_new assertion virtio-sound: add realize() error cleanup path virtio-snd: check AUD_register_card return value hw/audio/hda-codec: reenable the audio mixer hw/audio/hda-codec: fix multiplication overflow hw/audio/virtio-snd-pci: fix the PCI class code tests/acpi/bios-tables-test: do not write new blobs unless there are changes netdev: set timeout depending on loadavg osdep: add getloadavg Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-12-04hw/audio/virtio-sound: mark the device as unmigratableVolker Rümelin1-0/+1
The virtio-sound device is currently not migratable. QEMU crashes on the source machine at some point during the migration with a segmentation fault. Even with this bug fixed, the virtio-sound device doesn't migrate the state of the audio streams. For example, running streams leave the device on the destination machine in a broken condition. Mark the device as unmigratable until these issues have been fixed. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20231204072837.6058-1-vr_qemu@t-online.de>
2023-12-02vhost-user-scsi: free the inflight area when resetLi Feng2-1/+17
Keep it the same to vhost-user-blk. At the same time, fix the vhost_reset_device. Signed-off-by: Li Feng <fengli@smartx.com> Message-Id: <20231123055431.217792-3-fengli@smartx.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2025-01-09 10:31:45 +0000