aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-09-11docs/about/license: Update LICENSE URLPhilippe Mathieu-Daudé
In early 2021 (see commit 2ad784339e "docs: update README to use GitLab repo URLs") almost all of the code base was converted to point to GitLab instead of git.qemu.org. During 2023, git.qemu.org switched from a git mirror to a http redirect to GitLab (see [1]). Update the LICENSE URL to match its previous content, displaying the file raw content similarly to gitweb 'blob_plain' format ([2]). [1] https://lore.kernel.org/qemu-devel/CABgObfZu3mFc8tM20K-yXdt7F-7eV-uKZN4sKDarSeu7DYoRbA@mail.gmail.com/ [2] https://git-scm.com/docs/gitweb#Documentation/gitweb.txt-blobplain Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230822125716.55295-1-philmd@linaro.org> (cherry picked from commit 09a3fffae00b042bed8ad9c351b1a58c505fde37) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/arm: Fix 64-bit SSRARichard Henderson
Typo applied byte-wise shift instead of double-word shift. Cc: qemu-stable@nongnu.org Fixes: 631e565450c ("target/arm: Create gen_gvec_[us]sra") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1737 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230821022025.397682-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit cd1e4db73646006039f25879af3bff55b2295ff3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/arm: Fix SME ST1QRichard Henderson
A typo, noted in the bug report, resulting in an incorrect write offset. Cc: qemu-stable@nongnu.org Fixes: 7390e0e9ab8 ("target/arm: Implement SME LD1, ST1") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1833 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230818214255.146905-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4b3520fd93cd49cc56dfcab45d90735cc2e35af7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11accel/kvm: Specify default IPA size for arm64Akihiko Odaki
Before this change, the default KVM type, which is used for non-virt machine models, was 0. The kernel documentation says: > On arm64, the physical address size for a VM (IPA Size limit) is > limited to 40bits by default. The limit can be configured if the host > supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use > KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type > identifier, where IPA_Bits is the maximum width of any physical > address used by the VM. The IPA_Bits is encoded in bits[7-0] of the > machine type identifier. > > e.g, to configure a guest to use 48bit physical address size:: > > vm_fd = ioctl(dev_fd, KVM_CREATE_VM, KVM_VM_TYPE_ARM_IPA_SIZE(48)); > > The requested size (IPA_Bits) must be: > > == ========================================================= > 0 Implies default size, 40bits (for backward compatibility) > N Implies N bits, where N is a positive integer such that, > 32 <= N <= Host_IPA_Limit > == ========================================================= > Host_IPA_Limit is the maximum possible value for IPA_Bits on the host > and is dependent on the CPU capability and the kernel configuration. > The limit can be retrieved using KVM_CAP_ARM_VM_IPA_SIZE of the > KVM_CHECK_EXTENSION ioctl() at run-time. > > Creation of the VM will fail if the requested IPA size (whether it is > implicit or explicit) is unsupported on the host. https://docs.kernel.org/virt/kvm/api.html#kvm-create-vm So if Host_IPA_Limit < 40, specifying 0 as the type will fail. This actually confused libvirt, which uses "none" machine model to probe the KVM availability, on M2 MacBook Air. Fix this by using Host_IPA_Limit as the default type when KVM_CAP_ARM_VM_IPA_SIZE is available. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-3-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1ab445af8cd99343f29032b5944023ad7d8edebf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11kvm: Introduce kvm_arch_get_default_type hookAkihiko Odaki
kvm_arch_get_default_type() returns the default KVM type. This hook is particularly useful to derive a KVM type that is valid for "none" machine model, which is used by libvirt to probe the availability of KVM. For MIPS, the existing mips_kvm_type() is reused. This function ensures the availability of VZ which is mandatory to use KVM on the current QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-2-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added doc comment for new function] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5e0d65909c6f335d578b90491e165440c99adf81) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11include/hw/virtio/virtio-gpu: Fix virtio-gpu with blob on big endian hostsThomas Huth
Using "-device virtio-gpu,blob=true" currently does not work on big endian hosts (like s390x). The guest kernel prints an error message like: [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x10c) and the display stays black. When running QEMU with "-d guest_errors", it shows an error message like this: virtio_gpu_create_mapping_iov: nr_entries is too big (83886080 > 16384) which indicates that this value has not been properly byte-swapped. And indeed, the virtio_gpu_create_blob_bswap() function (that should swap the fields in the related structure) fails to swap some of the entries. After correctly swapping all missing values here, too, the virtio-gpu device is now also working with blob=true on s390x hosts. Fixes: e0933d91b1 ("virtio-gpu: Add virtio_gpu_resource_create_blob") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2230469 Message-Id: <20230815122007.928049-1-thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit d194362910138776e8abd6bb3c9fb3693254e95f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/s390x: Check reserved bits of VFMIN/VFMAX's M5Ilya Leoshkevich
VFMIN and VFMAX should raise a specification exceptions when bits 1-3 of M5 are set. Cc: qemu-stable@nongnu.org Fixes: da4807527f3b ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804234621.252522-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6a2ea6151835aa4f5fee29382a421c13b0e6619f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/s390x: Fix VSTL with a large lengthIlya Leoshkevich
The length is always truncated to 16 bytes. Do not probe more than that. Cc: qemu-stable@nongnu.org Fixes: 0e0a5b49ad58 ("s390x/tcg: Implement VECTOR STORE WITH LENGTH") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804235624.263260-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6db3518ba4fcddd71049718f138552999f0d97b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/s390x: Use a 16-bit immediate in VREPIlya Leoshkevich
Unlike most other instructions that contain an immediate element index, VREP's one is 16-bit, and not 4-bit. The code uses only 8 bits, so using, e.g., 0x101 does not lead to a specification exception. Fix by checking all 16 bits. Cc: qemu-stable@nongnu.org Fixes: 28d08731b1d8 ("s390x/tcg: Implement VECTOR REPLICATE") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230807163459.849766-1-iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 23e87d419f347b6b5f4da3bf70d222acc24cdb64) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11target/s390x: Fix the "ignored match" case in VSTRSIlya Leoshkevich
Currently the emulation of VSTRS recognizes partial matches in presence of \0 in the haystack, which, according to PoP, is not correct: If the ZS flag is one and a zero byte was detected in the second operand, then there can not be a partial match ... Add a check for this. While at it, fold a number of explicitly handled special cases into the generic logic. Cc: qemu-stable@nongnu.org Reported-by: Claudio Fontana <cfontana@suse.de> Closes: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00633.html Fixes: 1d706f314191 ("target/s390x: vxeh2: vector string search") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230804233748.218935-3-iii@linux.ibm.com> Tested-by: Claudio Fontana <cfontana@suse.de> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 791b2b6a930273db694b9ba48bbb406e78715927) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11Fixed incorrect LLONG alignment for openrisc and crisLuca Bonissi
OpenRISC (or1k) has long long alignment to 4 bytes, but currently not defined in abitypes.h. This lead to incorrect packing of /epoll_event/ structure and eventually infinite loop while waiting for file descriptor[s] event[s]. Fixed also CRIS alignments (1 byte for all types). Signed-off-by: Luca Bonissi <qemu@bonslack.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1770 Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 6ee960823da8fd780ae9912c4327b7e85e80d846) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for nios2Richard Henderson
Based on gcc's nios2.h setting BIGGEST_ALIGNMENT to 32 bits. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ea9812d93f9c3e1a308ac33097021c50d581d10e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11include/exec/user: Set ABI_LLONG_ALIGNMENT to 4 for microblazeRichard Henderson
Based on gcc's microblaze.h setting BIGGEST_ALIGNMENT to 32 bits. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e73f27003e777fd9b77d13e71c5268015b8ed2b6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11linux-user/elfload: Set V in ELF_HWCAP for RISC-VNathan Egge
Set V bit for hwcap if misa is set. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1793 Signed-off-by: Nathan Egge <negge@xiph.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230803131424.40744-1-negge@xiph.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4333f0924c2f2ca8efaebaed8c24f55f77d8b013) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw/nvme: fix CRC64 for guard tagAnkit Kumar
The nvme CRC64 generator expects the caller to pass inverted seed value. Pass inverted crc value for metadata buffer. Cc: qemu-stable@nongnu.org Fixes: 44219b6029fc ("hw/nvme: 64-bit pi support") Signed-off-by: Ankit Kumar <ankit.kumar@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit dbdb13f931d7cf2d3c3ca662e751bb1551e9eab6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11dump: kdump-zlib data pages not dumped with pvtime/aarch64Dongli Zhang
The kdump-zlib data pages are not dumped from aarch64 host when the 'pvtime' is involved, that is, when the block->target_end is not aligned to page_size. In the below example, it is expected to dump two blocks. (qemu) info mtree -f ... ... 00000000090a0000-00000000090a0fff (prio 0, ram): pvtime KVM ... ... 0000000040000000-00000001bfffffff (prio 0, ram): mach-virt.ram KVM ... ... However, there is an issue with get_next_page() so that the pages for "mach-virt.ram" will not be dumped. At line 1296, although we have reached at the end of the 'pvtime' block, since it is not aligned to the page_size (e.g., 0x10000), it will not break at line 1298. 1255 static bool get_next_page(GuestPhysBlock **blockptr, uint64_t *pfnptr, 1256 uint8_t **bufptr, DumpState *s) ... ... 1294 memcpy(buf + addr % page_size, hbuf, n); 1295 addr += n; 1296 if (addr % page_size == 0) { 1297 /* we filled up the page */ 1298 break; 1299 } As a result, get_next_page() will continue to the next block ("mach-virt.ram"). Finally, when get_next_page() returns to the caller: - 'pfnptr' is referring to the 'pvtime' - but 'blockptr' is referring to the "mach-virt.ram" When get_next_page() is called the next time, "*pfnptr += 1" still refers to the prior 'pvtime'. It will exit immediately because it is out of the range of the current "mach-virt.ram". The fix is to break when it is time to come to the next block, so that both 'pfnptr' and 'blockptr' refer to the same block. Fixes: 94d788408d2d ("dump: fix kdump to work over non-aligned blocks") Cc: Joe Jin <joe.jin@oracle.com> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230713055819.30497-1-dongli.zhang@oracle.com> (cherry picked from commit 8a64609eea8cb2bac015968c4b62da5bce266e22) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw/smbios: Fix core count in type4Zhao Liu
>From SMBIOS 3.0 specification, core count field means: Core Count is the number of cores detected by the BIOS for this processor socket. [1] Before 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology"), MachineState.smp.cores means "the number of cores in one package", and it's correct to use smp.cores for core count. But 003f230e37d7 changes the smp.cores' meaning to "the number of cores in one die" and doesn't change the original smp.cores' use in smbios as well, which makes core count in type4 go wrong. Fix this issue with the correct "cores per socket" caculation. [1] SMBIOS 3.0.0, section 7.5.6, Processor Information - Core Count Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 196ea60a734c346d7d75f1d89aa37703d4d854e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw/smbios: Fix thread count in type4Zhao Liu
>From SMBIOS 3.0 specification, thread count field means: Thread Count is the total number of threads detected by the BIOS for this processor socket. It is a processor-wide count, not a thread-per-core count. [1] So here we should use threads per socket other than threads per core. [1] SMBIOS 3.0.0, section 7.5.8, Processor Information - Thread Count Fixes: c97294ec1b9e ("SMBIOS: Build aggregate smbios tables and entry point") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-4-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 7298fd7de5551c4501f54381228458e3c21cab4b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw/smbios: Fix smbios_smp_sockets caculationZhao Liu
smp.sockets is the number of sockets which is configured by "-smp" ( otherwise, the default is 1). Trying to recalculate it here with another rules leads to errors, such as: 1. 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") changes the meaning of smp.cores but doesn't fix original smp.cores uses. With the introduction of cluster, now smp.cores means the number of cores in one cluster. So smp.cores * smp.threads just means the threads in a cluster not in a socket. 2. On the other hand, we shouldn't use smp.cpus here because it indicates the initial number of online CPUs at the boot time, and is not mathematically related to smp.sockets. So stop reinventing the another wheel and use the topo values that has been calculated. Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-3-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit d79a284a44bb7d88b233fb6bb12ea3723f43469d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11machine: Add helpers to get cores/threads per socketZhao Liu
The number of cores/threads per socket are needed for smbios, and are also useful for other modules. Provide the helpers to wrap the calculation of cores/threads per socket so that we can avoid calculation errors caused by other modules miss topology changes. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-2-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a1d027be95bc375238e5b9292c6aa661a8ddef4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11pnv_lpc: disable reentrancy detection for lpc-hcAlexander Bulekov
As lpc-hc is designed for re-entrant calls from xscom, mark it re-entrancy safe. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> [clg: mark opb_master_regs as re-entrancy safe also ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230526073850.2772197-1-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 76f9ebffcd41b62ae9ec26a1c25676f2ae1d9cc3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11loongarch: mark loongarch_ipi_iocsr re-entrnacy safeAlexander Bulekov
loongarch_ipi_iocsr MRs rely on re-entrant IO through the ipi_send function. As such, mark these MRs re-entrancy-safe. Fixes: a2e1753b80 ("memory: prevent dma-reentracy issues") Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20230506112145.3563708-1-alxndr@bu.edu> Signed-off-by: Song Gao <gaosong@loongson.cn> (cherry picked from commit 6d0589e0e6c64b888864a2bf980537be20389264) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11apic: disable reentrancy detection for apic-msiAlexander Bulekov
As the code is designed for re-entrant calls to apic-msi, mark apic-msi as reentrancy-safe. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20230427211013.2994127-9-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 50795ee051a342c681a9b45671c552fbd6274db8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11raven: disable reentrancy detection for iomemAlexander Bulekov
As the code is designed for re-entrant calls from raven_io_ops to pci-conf, mark raven_io_ops as reentrancy-safe. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20230427211013.2994127-8-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6dad5a6810d9c60ca320d01276f6133bbcfa1fc7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11bcm2835_property: disable reentrancy detection for iomemAlexander Bulekov
As the code is designed for re-entrant calls from bcm2835_property to bcm2835_mbox and back into bcm2835_property, mark iomem as reentrancy-safe. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230427211013.2994127-7-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 985c4a4e547afb9573b6bd6843d20eb2c3d1d1cd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11lsi53c895a: disable reentrancy detection for MMIO region, tooThomas Huth
While trying to use a SCSI disk on the LSI controller with an older version of Fedora (25), I'm getting: qemu: warning: Blocked re-entrant IO on MemoryRegion: lsi-mmio at addr: 0x34 and the SCSI controller is not usable. Seems like we have to disable the reentrancy checker for the MMIO region, too, to get this working again. The problem could be reproduced it like this: ./qemu-system-x86_64 -accel kvm -m 2G -machine q35 \ -device lsi53c810,id=lsi1 -device scsi-hd,drive=d0 \ -drive if=none,id=d0,file=.../somedisk.qcow2 \ -cdrom Fedora-Everything-netinst-i386-25-1.3.iso Where somedisk.qcow2 is an image that contains already some partitions and file systems. In the boot menu of Fedora, go to "Troubleshooting" -> "Rescue a Fedora system" -> "3) Skip to shell" Then check "dmesg | grep -i 53c" for failure messages, and try to mount a partition from somedisk.qcow2. Message-Id: <20230516090556.553813-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit d139fe9ad8a27bcc50b4ead77d2f97d191a0e95e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11lsi53c895a: disable reentrancy detection for script RAMAlexander Bulekov
As the code is designed to use the memory APIs to access the script ram, disable reentrancy checks for the pseudo-RAM ram_io MemoryRegion. In the future, ram_io may be converted from an IO to a proper RAM MemoryRegion. Reported-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20230427211013.2994127-6-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit bfd6e7ae6a72b84e2eb9574f56e6ec037f05182c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw: replace most qemu_bh_new calls with qemu_bh_new_guardedAlexander Bulekov
This protects devices from bh->mmio reentrancy issues. Thanks: Thomas Huth <thuth@redhat.com> for diagnosing OS X test failure. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230427211013.2994127-5-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit f63192b0544af5d3e4d5edfd85ab520fcf671377) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11checkpatch: add qemu_bh_new/aio_bh_new checksAlexander Bulekov
Advise authors to use the _guarded versions of the APIs, instead. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20230427211013.2994127-4-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit ef56ffbdd6b0605dc1e305611287b948c970e236) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11async: avoid use-after-free on re-entrancy guardAlexander Bulekov
A BH callback can free the BH, causing a use-after-free in aio_bh_call. Fix that by keeping a local copy of the re-entrancy guard pointer. Buglink: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58513 Fixes: 9c86c97f12 ("async: Add an optional reentrancy guard to the BH API") Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20230501141956.3444868-1-alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 7915bd06f25e1803778081161bf6fa10c42dc7cd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11async: Add an optional reentrancy guard to the BH APIAlexander Bulekov
Devices can pass their MemoryReentrancyGuard (from their DeviceState), when creating new BHes. Then, the async API will toggle the guard before/after calling the BH call-back. This prevents bh->mmio reentrancy issues. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20230427211013.2994127-3-alxndr@bu.edu> [thuth: Fix "line over 90 characters" checkpatch.pl error] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 9c86c97f12c060bf7484dd931f38634e166a81f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> [mjt: minor context adjustment in include/block/aio.h and include/qemu/main-loop.h for 7.2]
2023-09-11memory: prevent dma-reentracy issuesAlexander Bulekov
Add a flag to the DeviceState, when a device is engaged in PIO/MMIO/DMA. This flag is set/checked prior to calling a device's MemoryRegion handlers, and set when device code initiates DMA. The purpose of this flag is to prevent two types of DMA-based reentrancy issues: 1.) mmio -> dma -> mmio case 2.) bh -> dma write -> mmio case These issues have led to problems such as stack-exhaustion and use-after-frees. Summary of the problem from Peter Maydell: https://lore.kernel.org/qemu-devel/CAFEAcA_23vc7hE3iaM-JVA6W38LK4hJoWae5KcknhPRD5fPBZA@mail.gmail.com Resolves: https://gitlab.com/qemu-project/qemu/-/issues/62 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/540 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/541 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/556 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/557 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/827 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1282 Resolves: CVE-2023-0330 Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230427211013.2994127-2-alxndr@bu.edu> [thuth: Replace warn_report() with warn_report_once()] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit a2e1753b8054344f32cf94f31c6399a58794a380) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11python: drop pipenvJohn Snow
The pipenv tool was nice in theory, but in practice it's just too hard to update selectively, and it makes using it a pain. The qemu.qmp repo dropped pipenv support a while back and it's been functioning just fine, so I'm backporting that change here to qemu.git. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20230210003147.1309376-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit 6832189fd791622c30e7bbe3a12b76be14dc1158) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: the reason for this is to stop CI failing in pipenv for 7.2)
2023-09-11gitlab-ci: check-dco.py: switch from master to stable-7.2 branchMichael Tokarev
There's one commit, tagged v7.2.2, without Signed-off-by line. Due to this, check-dco test always fail on 7.2. Since this is a stable branch with almost all commits coming from master already with S-o-b (except of the version bumps and very rare stable-specific commits), and v7.2.2 is already cast in stone, let's base the check on stable-7.2 branch (with its last version) instead of master branch. This way, staging-7.2 will be checked against stable-7.2, but stable-7.2 itself will not be checked anymore, - so we can catch errors during stable preparations. Note: this is a change specific to stable-7.2 branch/series, it is not supposed to be in master. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Thomas Huth <thuth@redhat.com>
2023-08-07Update version for 7.2.5 releasev7.2.5Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05target/i386: Check CR0.TS before enter_mmxMatt Borgerson
When CR0.TS=1, execution of x87 FPU, MMX, and some SSE instructions will cause a Device Not Available (DNA) exception (#NM). System software uses this exception event to lazily context switch FPU state. Before this patch, enter_mmx helpers may be generated just before #NM generation, prematurely resetting FPU state before the guest has a chance to save it. Signed-off-by: Matt Borgerson <contact@mborgerson.com> Message-ID: <CADc=-s5F10muEhLs4f3mxqsEPAHWj0XFfOC2sfFMVHrk9fcpMg@mail.gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b2ea6450d8e1336a33eb958ccc64604bc35a43dd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05target/ppc: Fix VRMA page size for ISA v3.0Nicholas Piggin
Until v2.07s, the VRMA page size (L||LP) was encoded in LPCR[VRMASD]. In v3.0 that moved to the partition table PS field. The powernv machine can now run KVM HPT guests on POWER9/10 CPUs with this fix and the patch to add ASDR. Fixes: 3367c62f522b ("target/ppc: Support for POWER9 native hash") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-ID: <20230730111842.39292-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 0e2a3ec36885f6d79a96230f582d4455878c6373) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05target/ppc: Fix pending HDEC when entering PM stateNicholas Piggin
HDEC is defined to not wake from PM state. There is a check in the HDEC timer to avoid setting the interrupt if we are in a PM state, but no check on PM entry to lower HDEC if it already fired. This can cause a HDECR wake up and QEMU abort with unsupported exception in Power Save mode. Fixes: 4b236b621bf ("ppc: Initial HDEC support") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-ID: <20230726182230.433945-4-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 9915dac4847f3cc5ffd36e4c374a4eec83fe09b5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05target/ppc: Implement ASDR register for ISA v3.0 for HPTNicholas Piggin
The ASDR register was introduced in ISA v3.0. It has not been implemented for HPT. With HPT, ASDR is the format of the slbmte RS operand (containing VSID), which matches the ppc_slb_t field. Fixes: 3367c62f522b ("target/ppc: Support for POWER9 native hash") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-ID: <20230726182230.433945-2-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 9201af096962a1967ce5d0b270ed16ae4edd3db6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mq()Hawkins Jiawei
According to VirtIO standard, "The class, command and command-specific-data are set by the driver, and the device sets the ack byte. There is little it can do except issue a diagnostic if ack is not VIRTIO_NET_OK." Therefore, QEMU should stop sending the queued SVQ commands and cancel the device startup if the device's ack is not VIRTIO_NET_OK. Yet the problem is that, vhost_vdpa_net_load_mq() returns 1 based on `*s->status != VIRTIO_NET_OK` when the device's ack is VIRTIO_NET_ERR. As a result, net->nc->info->load() also returns 1, this makes vhost_net_start_one() incorrectly assume the device state is successfully loaded by vhost_vdpa_net_load() and return 0, instead of goto `fail` label to cancel the device startup, as vhost_net_start_one() only cancels the device startup when net->nc->info->load() returns a negative value. This patch fixes this problem by returning -EIO when the device's ack is not VIRTIO_NET_OK. Fixes: f64c7cda69 ("vdpa: Add vhost_vdpa_net_load_mq") Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <ec515ebb0b4f56368751b9e318e245a5d994fa72.1688438055.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit f45fd95ec9e8104f6af801c734375029dda0f542) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05vdpa: Return -EIO if device ack is VIRTIO_NET_ERR in _load_mac()Hawkins Jiawei
According to VirtIO standard, "The class, command and command-specific-data are set by the driver, and the device sets the ack byte. There is little it can do except issue a diagnostic if ack is not VIRTIO_NET_OK." Therefore, QEMU should stop sending the queued SVQ commands and cancel the device startup if the device's ack is not VIRTIO_NET_OK. Yet the problem is that, vhost_vdpa_net_load_mac() returns 1 based on `*s->status != VIRTIO_NET_OK` when the device's ack is VIRTIO_NET_ERR. As a result, net->nc->info->load() also returns 1, this makes vhost_net_start_one() incorrectly assume the device state is successfully loaded by vhost_vdpa_net_load() and return 0, instead of goto `fail` label to cancel the device startup, as vhost_net_start_one() only cancels the device startup when net->nc->info->load() returns a negative value. This patch fixes this problem by returning -EIO when the device's ack is not VIRTIO_NET_OK. Fixes: f73c0c43ac ("vdpa: extract vhost_vdpa_net_load_mac from vhost_vdpa_net_load") Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <a21731518644abbd0c495c5b7960527c5911f80d.1688438055.git.yin31149@gmail.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit b479bc3c9d5e473553137641fd31069c251f0d6e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05vdpa: Fix possible use-after-free for VirtQueueElementHawkins Jiawei
QEMU uses vhost_handle_guest_kick() to forward guest's available buffers to the vdpa device in SVQ avail ring. In vhost_handle_guest_kick(), a `g_autofree` `elem` is used to iterate through the available VirtQueueElements. This `elem` is then passed to `svq->ops->avail_handler`, specifically to the vhost_vdpa_net_handle_ctrl_avail(). If this handler fails to process the CVQ command, vhost_handle_guest_kick() regains ownership of the `elem`, and either frees it or requeues it. Yet the problem is that, vhost_vdpa_net_handle_ctrl_avail() mistakenly frees the `elem`, even if it fails to forward the CVQ command to vdpa device. This can result in a use-after-free for the `elem` in vhost_handle_guest_kick(). This patch solves this problem by refactoring vhost_vdpa_net_handle_ctrl_avail() to only freeing the `elem` if it owns it. Fixes: bd907ae4b0 ("vdpa: manual forward CVQ buffers") Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Message-Id: <e3f2d7db477734afe5c6a5ab3fa8b8317514ea34.1688746840.git.yin31149@gmail.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 031b1abacbdb3f4e016b6b926f7e7876c05339bb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-05vfio/pci: Disable INTx in vfio_realize error pathZhenzhong Duan
When vfio realize fails, INTx isn't disabled if it has been enabled. This may confuse host side with unhandled interrupt report. Fixes: c5478fea27ac ("vfio/pci: Respond to KVM irqchip change notifier") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> (cherry picked from commit adee0da0368f50b3ee934cdeeb6076466dabb268) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04include/hw/i386/x86-iommu: Fix struct X86IOMMU_MSIMessage for big endian hostsThomas Huth
The first bitfield here is supposed to be used as a 64-bit equivalent to the "uint64_t msi_addr" in the union. To make this work correctly on big endian hosts, too, the __addr_hi field has to be part of the bitfield, and the the bitfield members must be declared with "uint64_t" instead of "uint32_t" - otherwise the values are placed in the wrong bytes on big endian hosts. Same applies to the 32-bit "msi_data" field: __resved1 must be part of the bitfield, and the members must be declared with "uint32_t" instead of "uint16_t". Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-7-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit e1e56c07d1fa24aa37a7e89e6633768fc8ea8705) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04hw/i386/x86-iommu: Fix endianness issue in x86_iommu_irq_to_msi_message()Thomas Huth
The values in "msg" are assembled in host endian byte order (the other field are also not swapped), so we must not swap the __addr_head here. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-6-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 37cf5cecb039a063c0abe3b51ae30f969e73aa84) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04hw/i386/intel_iommu: Fix index calculation in vtd_interrupt_remap_msi()Thomas Huth
The values in "addr" are populated locally in this function in host endian byte order, so we must not swap the index_l field here. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-5-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit fcd8027423300b201b37842b88393dc5c6c8ee9e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04hw/i386/intel_iommu: Fix struct VTDInvDescIEC on big endian hostsThomas Huth
On big endian hosts, we need to reverse the bitfield order in the struct VTDInvDescIEC, just like it is already done for the other bitfields in the various structs of the intel-iommu device. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-4-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 4572b22cf9ba432fa3955686853c706a1821bbc7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04hw/i386/intel_iommu: Fix endianness problems related to VTD_IR_TableEntryThomas Huth
The code already tries to do some endianness handling here, but currently fails badly: - While it already swaps the data when logging errors / tracing, it fails to byteswap the value before e.g. accessing entry->irte.present - entry->irte.source_id is swapped with le32_to_cpu(), though this is a 16-bit value - The whole union is apparently supposed to be swapped via the 64-bit data[2] array, but the struct is a mixture between 32 bit values (the first 8 bytes) and 64 bit values (the second 8 bytes), so this cannot work as expected. Fix it by converting the struct to two proper 64-bit bitfields, and by swapping the values only once for everybody right after reading the data from memory. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-3-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 642ba89672279fbdd14016a90da239c85e845d18) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04hw/i386/intel_iommu: Fix trivial endianness problemsThomas Huth
After reading the guest memory with dma_memory_read(), we have to make sure that we byteswap the little endian data to the host's byte order. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230802135723.178083-2-thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> (cherry picked from commit cc2a08480e19007c05be8fe5b6893e20448954dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04pci: do not respond config requests after PCI device ejectYuri Benditovich
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2224964 In migration with VF failover, Windows guest and ACPI hot unplug we do not need to satisfy config requests, otherwise the guest immediately detects the device and brings up its driver. Many network VF's are stuck on the guest PCI bus after the migration. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Message-Id: <20230728084049.191454-1-yuri.benditovich@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 348e354417b64c484877354ee7cc66f29fa6c7df) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 06:09:15 +0000