aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-10gdbstub: reject unsupported flags in handle_set_qemu_sstepMaxim Levitsky
handle_query_qemu_sstepbits is reporting NOIRQ and NOTIMER bits even if they are not supported (as is the case with record/replay). Instead, store the supported singlestep flags and reject any unsupported bits in handle_set_qemu_sstep. This removes the need for the get_sstep_flags() wrapper. While at it, move the variables in GDBState, instead of using global variables. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> [Extracted from Maxim's patch into a separate commit. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211111110604.207376-4-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-10linux-headers: update to 5.16-rc1Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211111110604.207376-3-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-10virtio-gpu: do not byteswap paddingPaolo Bonzini
In Linux 5.16, the padding of struct virtio_gpu_ctrl_hdr has become a single-byte field followed by a uint8_t[3] array of padding bytes, and virtio_gpu_ctrl_hdr_bswap does not compile anymore. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211111110604.207376-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-30scripts/entitlement.sh: Use backward-compatible cp flagsEvan Miller
Older versions of Mac OS X do not support cp -a. The cp man page indicates that -a is equivalent to -pPR. Signed-off-by: Evan Miller <emmiller@gmail.com> Message-Id: <40635C6E-059A-4146-B1E2-F6376700EE85@gmail.com> [Leave out -R, these are files and not directories. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-30qapi/machine.json: Fix incorrect description for die-idYanan Wang
In terms of scope, die-id should mean "the die number within socket the CPU belongs to" instead of "the die number within node/board the CPU belongs to". Fix it to avoid confusing the Doc reader. Fixes: 176d2cda0d ("i386/cpu: Consolidate die-id validity in smp context") Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20211122032651.16064-1-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-30tests/qtest: Add fuzz-lsi53c895a-testPhilippe Mathieu-Daudé
Without the previous commit, this test triggers: $ make check-qtest-x86_64 [...] Running test qtest-x86_64/fuzz-lsi53c895a-test qemu-system-x86_64: hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed. ERROR qtest-x86_64/fuzz-lsi53c895a-test - too few tests run (expected 1, got 0) Suggested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20211123111732.83137-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-30hw/scsi/lsi53c895a: Do not abort when DMA requested and no data queuedPhilippe Mathieu-Daudé
If asked for DMA request and no data is available, simply wait for data to be queued, do not abort. This fixes: $ cat << EOF | \ qemu-system-i386 -nographic -M q35,accel=qtest -serial none \ -monitor none -qtest stdio -trace lsi* \ -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw \ -device lsi53c895a,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 lsi_reset Reset lsi_reg_write Write reg DSP2 0x2e = 0xff lsi_reg_write Write reg DSP3 0x2f = 0xff lsi_execute_script SCRIPTS dsp=0xffff0000 opcode 0x184a3900 arg 0x4a8b2d75 qemu-system-i386: hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed. (gdb) bt #5 0x00007ffff4e8a3a6 in __GI___assert_fail (assertion=0x5555560accbc "s->current", file=0x5555560acc28 "hw/scsi/lsi53c895a.c", line=624, function=0x5555560adb18 "lsi_do_dma") at assert.c:101 #6 0x0000555555aa33b9 in lsi_do_dma (s=0x555557805ac0, out=1) at hw/scsi/lsi53c895a.c:624 #7 0x0000555555aa5042 in lsi_execute_script (s=0x555557805ac0) at hw/scsi/lsi53c895a.c:1250 #8 0x0000555555aa757a in lsi_reg_writeb (s=0x555557805ac0, offset=47, val=255 '\377') at hw/scsi/lsi53c895a.c:1984 #9 0x0000555555aa875b in lsi_mmio_write (opaque=0x555557805ac0, addr=47, val=255, size=1) at hw/scsi/lsi53c895a.c:2095 Cc: qemu-stable@nongnu.org Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Vadim Rozenfeld <vrozenfe@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reported-by: Jérôme Poulin <jeromepoulin@gmail.com> Reported-by: Ruhr-University <bugs-syssec@rub.de> Reported-by: Gaoning Pan <pgn@zju.edu.cn> Reported-by: Cheolwoo Myung <cwmyung@snu.ac.kr> Fixes: b96a0da06bd ("lsi: move dma_len+dma_buf into lsi_request") BugLink: https://bugs.launchpad.net/qemu/+bug/697510 BugLink: https://bugs.launchpad.net/qemu/+bug/1905521 BugLink: https://bugs.launchpad.net/qemu/+bug/1908515 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/84 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/305 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/552 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20211123111732.83137-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-11-29Merge tag 'pull-ppc-20211129' of https://github.com/legoater/qemu into stagingRichard Henderson
ppc 6.2 queue: * Hash64 MMU fix for FreeBSD installer # gpg: Signature made Mon 29 Nov 2021 09:49:54 PM CET # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-ppc-20211129' of https://github.com/legoater/qemu: target/ppc: fix Hash64 MMU update of PTE bit R Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-29target/ppc: fix Hash64 MMU update of PTE bit RLeandro Lupori
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte offset, causing the first byte of the adjacent PTE to be corrupted. This caused a panic when booting FreeBSD, using the Hash MMU. Fixes: a2dd4e83e76b ("ppc/hash64: Rework R and C bit updates") Signed-off-by: Leandro Lupori <leandro.lupori@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-11-29Merge tag 'pull-for-6.2-291121-1' of https://github.com/stsquad/qemu into ↵Richard Henderson
staging TCG, plugin and build fixes: - introduce CF_NOIRQ to avoid watchpoint race - fix avocado plugin test - fix linker issue with weird paths - band-aid for gdbstub race - updates for MAINTAINERS - fix some compiler warning in example plugin # gpg: Signature made Mon 29 Nov 2021 04:16:22 PM CET # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] * tag 'pull-for-6.2-291121-1' of https://github.com/stsquad/qemu: tests/plugin/syscall.c: fix compiler warnings MAINTAINERS: Add section for Aarch64 GitLab custom runner MAINTAINERS: Remove me as a reviewer for the build and test/avocado gdbstub: handle a potentially racing TaskState plugins/meson.build: fix linker issue with weird paths tests/avocado: fix tcg_plugin mem access count test accel/tcg: suppress IRQ check for special TBs accel/tcg: introduce CF_NOIRQ Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-29Merge tag 'linux-user-for-6.2-pull-request' of git://github.com/vivier/qemu ↵Richard Henderson
into staging linux-user pull request 20211129 Fix losetup # gpg: Signature made Mon 29 Nov 2021 03:04:30 PM CET # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] * tag 'linux-user-for-6.2-pull-request' of git://github.com/vivier/qemu: linux-user: implement more loop ioctls Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-29tests/plugin/syscall.c: fix compiler warningsJuro Bystricky
Fix compiler warnings. The warnings can result in a broken build. This patch fixes warnings such as: In file included from /usr/include/glib-2.0/glib.h:111, from ../tests/plugin/syscall.c:13: ../tests/plugin/syscall.c: In function ‘print_entry’: /usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: ‘out’ may be used uninitialized in this function [-Werror=maybe-uninitialized] g_free (*pp); ^~~~~~~~~~~~ ../tests/plugin/syscall.c:82:23: note: ‘out’ was declared here g_autofree gchar *out; ^~~ In file included from /usr/include/glib-2.0/glib.h:111, from ../tests/plugin/syscall.c:13: ../tests/plugin/syscall.c: In function ‘vcpu_syscall_ret’: /usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: ‘out’ may be used uninitialized in this function [-Werror=maybe-uninitialized] g_free (*pp); ^~~~~~~~~~~~ ../tests/plugin/syscall.c:73:27: note: ‘out’ was declared here g_autofree gchar *out; ^~~ cc1: all warnings being treated as errors Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211128011551.2115468-1-juro.bystricky@intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211129140932.4115115-9-alex.bennee@linaro.org>
2021-11-29MAINTAINERS: Add section for Aarch64 GitLab custom runnerPhilippe Mathieu-Daudé
Add a MAINTAINERS section to cover the GitLab YAML config file containing the jobs run on the custom runner sponsored by the Works On Arm project [*]. [*] https://developer.arm.com/solutions/infrastructure/works-on-arm Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211116163226.2719320-1-f4bug@amsat.org> Message-Id: <20211129140932.4115115-8-alex.bennee@linaro.org>
2021-11-29MAINTAINERS: Remove me as a reviewer for the build and test/avocadoWillian Rampazzo
Remove me as a reviewer for the Build and test automation and the Integration Testing with the Avocado Framework and add Beraldo Leal. Signed-off-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Beraldo Leal <bleal@redhat.com> Message-Id: <20211122191124.31620-1-willianr@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211129140932.4115115-7-alex.bennee@linaro.org>
2021-11-29gdbstub: handle a potentially racing TaskStateAlex Bennée
When dealing with multi-threaded userspace programs there is a race condition with the addition of cpu->opaque (aka TaskState). This is due to cpu_copy calling cpu_create which updates the global vCPU list. However the task state isn't set until later. This shouldn't be a problem because the new thread can't have executed anything yet but the gdbstub code does liberally iterate through the CPU list in various places. This sticking plaster ensure the not yet fully realized vCPU is given an pid of -1 which should be enough to ensure it doesn't show up anywhere else. In the longer term I think the code that manages the association between vCPUs and attached GDB processes could do with a clean-up and re-factor. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Richard Henderson <richard.henderson@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/730 Message-Id: <20211129140932.4115115-6-alex.bennee@linaro.org>
2021-11-29plugins/meson.build: fix linker issue with weird pathsAlex Bennée
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Stefan Weil <sw@weilnetz.de> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/712 Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211129140932.4115115-5-alex.bennee@linaro.org>
2021-11-29tests/avocado: fix tcg_plugin mem access count testAlex Bennée
When we cleaned up argument handling the test was missed. Fixes: 5ae589faad ("tests/plugins/mem: introduce "track" arg and make args not positional") Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211129140932.4115115-4-alex.bennee@linaro.org>
2021-11-29accel/tcg: suppress IRQ check for special TBsAlex Bennée
When we set cpu->cflags_next_tb it is because we want to carefully control the execution of the next TB. Currently there is a race that causes the second stage of watchpoint handling to get ignored if an IRQ is processed before we finish executing the instruction that triggers the watchpoint. Use the new CF_NOIRQ facility to avoid the race. We also suppress IRQs when handling precise self modifying code to avoid unnecessary bouncing. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/245 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211129140932.4115115-3-alex.bennee@linaro.org>
2021-11-29accel/tcg: introduce CF_NOIRQAlex Bennée
Here we introduce a new compiler flag to disable the checking of exit request (icount_decr.u32). This is useful when we want to ensure the next block cannot be preempted by an asynchronous event. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211129140932.4115115-2-alex.bennee@linaro.org>
2021-11-29Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson
into staging virtio,pci,pc: bugfixes Lots of small fixes all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 29 Nov 2021 02:50:06 PM CET # 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] * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: Fix bad overflow check in hw/pci/pcie.c intel-iommu: ignore leaf SNP bit in scalable mode virtio-balloon: correct used length virtio-balloon: process all in sgs for free_page_vq vdpa: Add dummy receive callback failover: fix unplug pending detection virtio-mmio : fix the crash in the vm shutdown Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-29linux-user: implement more loop ioctlsAndreas Schwab
LOOP_CONFIGURE is now used by losetup, and it cannot cope with ENOSYS. Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <mvmtug4mbfx.fsf_-_@suse.de> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-11-29Fix bad overflow check in hw/pci/pcie.cDaniella Lee
Orginal qemu commit hash:14d02cfbe4adaeebe7cb833a8cc71191352cf03b In function pcie_add_capability, an assert contains the "offset < offset + size" expression. Both variable offset and variable size are uint16_t, the comparison is always true due to type promotion. The next expression may be the same. It might be like this: Thread 1 "qemu-system-x86" hit Breakpoint 1, pcie_add_capability ( dev=0x555557ce5f10, cap_id=1, cap_ver=2 '\002', offset=256, size=72) at ../hw/pci/pcie.c:930 930 { (gdb) n 931 assert(offset >= PCI_CONFIG_SPACE_SIZE); (gdb) n 932 assert(offset < offset + size); (gdb) p offset $1 = 256 (gdb) p offset < offset + size $2 = 1 (gdb) set offset=65533 (gdb) p offset < offset + size $3 = 1 (gdb) p offset < (uint16_t)(offset + size) $4 = 0 Signed-off-by: Daniella Lee <daniellalee111@gmail.com> Message-Id: <20211126061324.47331-1-daniellalee111@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-29intel-iommu: ignore leaf SNP bit in scalable modeJason Wang
When booting with scalable mode, I hit this error: qemu-system-x86_64: vtd_iova_to_slpte: detected splte reserve non-zero iova=0xfffff002, level=0x1slpte=0x102681803) qemu-system-x86_64: vtd_iommu_translate: detected translation failure (dev=01:00:00, iova=0xfffff002) qemu-system-x86_64: New fault is not recorded due to compression of faults This is because the SNP bit is set for second level page table since Linux kernel commit 6c00612d0cba1 ("iommu/vt-d: Report right snoop capability when using FL for IOVA") even if SC is not supported by the hardware. To unbreak the guest, ignore the leaf SNP bit for scalable mode first. In the future we may consider to add SC support. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211129033618.3857-1-jasowang@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>
2021-11-29virtio-balloon: correct used lengthJason Wang
Spec said: "and len the total of bytes written into the buffer." For inflateq, deflateq and statsq, we don't process in_sg so the used length should be zero. For free_page_vq, tough the pages could be changed by the device (in the destination), spec said: "Note: len is particularly useful for drivers using untrusted buffers: if a driver does not know exactly how much has been written by the device, the driver would have to zero the buffer in advance to ensure no data leakage occurs." So 0 should be used as well here. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211129030841.3611-2-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com>
2021-11-29virtio-balloon: process all in sgs for free_page_vqJason Wang
We only process the first in sg which may lead to the bitmap of the pages belongs to following sgs were not cleared. This may result more pages to be migrated. Fixing this by process all in sgs for free_page_vq. Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20211129030841.3611-1-jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-29Merge tag 'pull-target-arm-20211129' of ↵Richard Henderson
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * virt: Diagnose attempts to enable MTE or virt when using HVF accelerator * GICv3 ITS: Allow clearing of ITS CTLR Enabled bit * GICv3: Update cached state after LPI state changes * GICv3: Fix handling of LPIs in list registers # gpg: Signature made Mon 29 Nov 2021 11:34:46 AM CET # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] * tag 'pull-target-arm-20211129' of https://git.linaro.org/people/pmaydell/qemu-arm: hw/intc/arm_gicv3: fix handling of LPIs in list registers hw/intc/arm_gicv3: Add new gicv3_intid_is_special() function hw/intc/arm_gicv3: Update cached state after LPI state changes hw/intc: cannot clear GICv3 ITS CTLR[Enabled] bit hw/arm/virt: Extend nested and mte checks to hvf Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-29hw/intc/arm_gicv3: fix handling of LPIs in list registersPeter Maydell
It is valid for an OS to put virtual interrupt ID values into the list registers ICH_LR<n> which are greater than 1023. This corresponds to (for example) KVM using the in-kernel emulated ITS to give a (nested) guest an ITS. LPIs are delivered by the L1 kernel to the L2 guest via the list registers in the same way as non-LPI interrupts. QEMU's code for handling writes to ICV_IARn (which happen when the L2 guest acknowledges an interrupt) and to ICV_EOIRn (which happen at the end of the interrupt) did not consider LPIs, so it would incorrectly treat interrupt IDs above 1023 as invalid. Fix this by using the correct condition, which is gicv3_intid_is_special(). Note that the condition in icv_dir_write() is correct -- LPIs are not valid there and so we want to ignore both "special" ID values and LPIs. (In the pseudocode this logic is in: - VirtualReadIAR0(), VirtualReadIAR1(), which call IsSpecial() - VirtualWriteEOIR0(), VirtualWriteEOIR1(), which call VirtualIdentifierValid(data, TRUE) meaning "LPIs OK" - VirtualWriteDIR(), which calls VirtualIdentifierValid(data, FALSE) meaning "LPIs not OK") This bug doesn't seem to have any visible effect on Linux L2 guests most of the time, because the two bugs cancel each other out: we neither mark the interrupt active nor deactivate it. However it does mean that the L2 vCPU priority while the LPI handler is running will not be correct, so the interrupt handler could be unexpectedly interrupted by a different interrupt. (NB: this has nothing to do with using QEMU's emulated ITS.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org>
2021-11-28vdpa: Add dummy receive callbackEugenio Pérez
Qemu falls back on userland handlers even if vhost-user and vhost-vdpa cases. These assumes a tap device can handle the packets. If a vdpa device fail to start, it can trigger a sigsegv because of that. Add dummy receiver that returns no progress so it can keep running. Fixes: 1e0a84ea49 ("vhost-vdpa: introduce vhost-vdpa net client") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20211125101614.76927-2-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2021-11-28failover: fix unplug pending detectionLaurent Vivier
Failover needs to detect the end of the PCI unplug to start migration after the VFIO card has been unplugged. To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in pcie_unplug_device(). But since 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") we have switched to ACPI unplug and these functions are not called anymore and the flag not set. So failover migration is not able to detect if card is really unplugged and acts as it's done as soon as it's started. So it doesn't wait the end of the unplug to start the migration. We don't see any problem when we test that because ACPI unplug is faster than PCIe native hotplug and when the migration really starts the unplug operation is already done. See c000a9bd06ea ("pci: mark device having guest unplug request pending") a99c4da9fc2a ("pci: mark devices partially unplugged") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20211118133225.324937-4-lvivier@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-28virtio-mmio : fix the crash in the vm shutdownCindy Lu
The root cause for this crash is the ioeventfd not stopped while the VM stop. The callback for vmstate_change was not implement in virtio-mmio bus Reproduce step load the vm with -M microvm \ -netdev tap,id=net0,vhostforce,script=no,downscript=no \ -device virtio-net-device,netdev=net0\ After the VM boot, login the vm and then shutdown the vm System will crash [Current thread is 1 (Thread 0x7ffff6edde00 (LWP 374378))] (gdb) bt 0 0x00005555558f18b4 in qemu_flush_or_purge_queued_packets (purge=false, nc=0x55500252e850) at ../net/net.c:636 1 qemu_flush_queued_packets (nc=0x55500252e850) at ../net/net.c:656 2 0x0000555555b6c363 in virtio_queue_notify_vq (vq=0x7fffe7e2b010) at ../hw/virtio/virtio.c:2339 3 virtio_queue_host_notifier_read (n=0x7fffe7e2b08c) at ../hw/virtio/virtio.c:3583 4 0x0000555555de7b5a in aio_dispatch_handler (ctx=ctx@entry=0x5555567c5780, node=0x555556b83fd0) at ../util/aio-posix.c:329 5 0x0000555555de8454 in aio_dispatch_ready_handlers (ready_list=<optimized out>, ctx=<optimized out>) at ../util/aio-posix.c:359 6 aio_poll (ctx=0x5555567c5780, blocking=blocking@entry=false) at ../util/aio-posix.c:662 7 0x0000555555cce0cc in monitor_cleanup () at ../monitor/monitor.c:645 8 0x0000555555b06bd2 in qemu_cleanup () at ../softmmu/runstate.c:822 9 0x000055555586e693 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:51 Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20211109023744.22387-1-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-11-26hw/intc/arm_gicv3: Add new gicv3_intid_is_special() functionPeter Maydell
The GICv3/v4 pseudocode has a function IsSpecial() which returns true if passed a "special" interrupt ID number (anything between 1020 and 1023 inclusive). We open-code this condition in a couple of places, so abstract it out into a new function gicv3_intid_is_special(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2021-11-26hw/intc/arm_gicv3: Update cached state after LPI state changesPeter Maydell
The logic of gicv3_redist_update() is as follows: * it must be called in any code path that changes the state of (only) redistributor interrupts * if it finds a redistributor interrupt that is (now) higher priority than the previous highest-priority pending interrupt, then this must be the new highest-priority pending interrupt * if it does *not* find a better redistributor interrupt, then: - if the previous state was "no interrupts pending" then the new state is still "no interrupts pending" - if the previous best interrupt was not a redistributor interrupt then that remains the best interrupt - if the previous best interrupt *was* a redistributor interrupt, then the new best interrupt must be some non-redistributor interrupt, but we don't know which so must do a full scan In commit 17fb5e36aabd4b2c125 we effectively added the LPI interrupts as a kind of "redistributor interrupt" for this purpose, by adding cs->hpplpi to the set of things that gicv3_redist_update() considers before it gives up and decides to do a full scan of distributor interrupts. However we didn't quite get this right: * the condition check for "was the previous best interrupt a redistributor interrupt" must be updated to include LPIs in what it considers to be redistributor interrupts * every code path which updates the LPI state which gicv3_redist_update() checks must also call gicv3_redist_update(): this is cs->hpplpi and the GICR_CTLR ENABLE_LPIS bit This commit fixes this by: * correcting the test on cs->hppi.irq in gicv3_redist_update() * making gicv3_redist_update_lpi() always call gicv3_redist_update() * introducing a new gicv3_redist_update_lpi_only() for the one callsite (the post-load hook) which must not call gicv3_redist_update() * making gicv3_redist_lpi_pending() always call gicv3_redist_update(), either directly or via gicv3_redist_update_lpi() * removing a couple of now-unnecessary calls to gicv3_redist_update() from some callers of those two functions * calling gicv3_redist_update() when the GICR_CTLR ENABLE_LPIS bit is cleared (This means that the not-file-local gicv3_redist_* LPI related functions now all take care of the updates of internally cached GICv3 information, in the same way the older functions gicv3_redist_set_irq() and gicv3_redist_send_sgi() do.) The visible effect of this bug was that when the guest acknowledged an LPI by reading ICC_IAR1_EL1, we marked it as not pending in the LPI data structure but still left it in cs->hppi so we would offer it to the guest again. In particular for setups using an emulated GICv3 and ITS and using devices which use LPIs (ie PCI devices) a Linux guest would complain "irq 54: nobody cared" and then hang. (The hang was intermittent, presumably depending on the timing between different interrupts arriving and being completed.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20211124202005.989935-1-peter.maydell@linaro.org
2021-11-26hw/intc: cannot clear GICv3 ITS CTLR[Enabled] bitShashi Mallela
When Enabled bit is cleared in GITS_CTLR,ITS feature continues to be enabled.This patch fixes the issue. Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211124182246.67691-1-shashi.mallela@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-11-26hw/arm/virt: Extend nested and mte checks to hvfAlexander Graf
The virt machine has properties to enable MTE and Nested Virtualization support. However, its check to ensure the backing accel implementation supports it today only looks for KVM and bails out if it finds it. Extend the checks to HVF as well as it does not support either today. This will cause QEMU to print a useful error message rather than silently ignoring the attempt by the user to enable either MTE or the Virtualization extensions. Reported-by: saar amar <saaramar5@gmail.com> Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-id: 20211123122859.22452-1-agraf@csgraf.de Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-11-26Fix version for v6.2.0-rc2 releaseRichard Henderson
Typo while setting VERSION in the tag commit. Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-24Update version for v6.2.0-rc2 releaseRichard Henderson
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23Merge tag 'pull-block-2021-11-23' of https://gitlab.com/hreitz/qemu into stagingRichard Henderson
Block patches for 6.2-rc2: - Fix memory leak in vvfat when vvfat_open() fails - iotest fixes for the gnutls crypto backend # gpg: Signature made Tue 23 Nov 2021 04:58:05 PM CET # gpg: using RSA key CB62D7A0EE3829E45F004D34A1FA40D098019CDF # gpg: issuer "hreitz@redhat.com" # gpg: Good signature from "Hanna Reitz <hreitz@redhat.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: CB62 D7A0 EE38 29E4 5F00 4D34 A1FA 40D0 9801 9CDF * tag 'pull-block-2021-11-23' of https://gitlab.com/hreitz/qemu: iotests/149: Skip on unsupported ciphers iotests: Use aes-128-cbc block/vvfat.c fix leak when failure occurs Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23iotests/149: Skip on unsupported ciphersHanna Reitz
Whenever qemu-img or qemu-io report that some cipher is unsupported, skip the whole test, because that is probably because qemu has been configured with the gnutls crypto backend. We could taylor the algorithm list to what gnutls supports, but this is a test that is run rather rarely anyway (because it requires password-less sudo), and so it seems better and easier to skip it. When this test is intentionally run to check LUKS compatibility, it seems better not to limit the algorithms but keep the list extensive. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20211117151707.52549-3-hreitz@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-23iotests: Use aes-128-cbcHanna Reitz
Our gnutls crypto backend (which is the default as of 8bd0931f6) supports neither twofish-128 nor the CTR mode. CBC and aes-128 are supported by all of our backends (as far as I can tell), so use aes-128-cbc in our iotests. (We could also use e.g. aes-256-cbc, but the different key sizes would lead to different key slot offsets and so change the reference output more, which is why I went with aes-128.) Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20211117151707.52549-2-hreitz@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com>
2021-11-23block/vvfat.c fix leak when failure occursDaniella Lee
Function vvfat_open called function enable_write_target and init_directories, and these functions malloc new memory for BDRVVVFATState::qcow_filename, BDRVVVFATState::used_clusters, and BDRVVVFATState::cluster_buff. When the specified folder does not exist ,it may contains memory leak. After init_directories function is executed, the vvfat_open return -EIO, and bdrv_open_driver goto label open_failed, the program use g_free(bs->opaque) to release BDRVVVFATState struct without members mentioned. command line: qemu-system-x86_64 -hdb <vdisk qcow file> -usb -device usb-storage,drive=fat16 -drive file=fat:rw:fat-type=16:"<path of a host folder does not exist>", id=fat16,format=raw,if=none enable_write_target called: (gdb) bt at ../block/vvfat.c:3114 flags=155650, errp=0x7fffffffd780) at ../block/vvfat.c:1236 node_name=0x0, options=0x555556fa45d0, open_flags=155650, errp=0x7fffffffd890) at ../block.c:1558 errp=0x7fffffffd890) at ../block.c:1852 reference=0x0, options=0x555556fa45d0, flags=40962, parent=0x555556f98cd0, child_class=0x555556b1d6a0 <child_of_bds>, child_role=19, errp=0x7fffffffda90) at ../block.c:3779 options=0x555556f9cfc0, bdref_key=0x555556239bb8 "file", parent=0x555556f98cd0, child_class=0x555556b1d6a0 <child_of_bds>, child_role=19, allow_none=true, errp=0x7fffffffda90) at ../block.c:3419 reference=0x0, options=0x555556f9cfc0, flags=8194, parent=0x0, child_class=0x0, child_role=0, errp=0x555556c98c40 <error_fatal>) at ../block.c:3726 options=0x555556f757b0, flags=0, errp=0x555556c98c40 <error_fatal>) at ../block.c:3872 options=0x555556f757b0, flags=0, errp=0x555556c98c40 <error_fatal>) at ../block/block-backend.c:436 bs_opts=0x555556f757b0, errp=0x555556c98c40 <error_fatal>) at ../blockdev.c:608 errp=0x555556c98c40 <error_fatal>) at ../blockdev.c:992 ...... Signed-off-by: Daniella Lee <daniellalee111@gmail.com> Message-Id: <20211119112553.352222-1-daniellalee111@gmail.com> [hreitz: Took commit message from v1] Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2021-11-23Merge tag 'pull-lu-20211123' of https://gitlab.com/rth7680/qemu into stagingRichard Henderson
Create common rewind_if_in_safe_syscall function. Resolves pointer type issues with uc_mcontext.pc on aarch64 between glibc and musl. # gpg: Signature made Tue 23 Nov 2021 09:47:07 AM CET # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate] * tag 'pull-lu-20211123' of https://gitlab.com/rth7680/qemu: linux-user/signal.c: Create a common rewind_if_in_safe_syscall linux-user: Add host_signal_set_pc to set pc in mcontext Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23Merge tag 'python-pull-request' of https://gitlab.com/jsnow/qemu into stagingRichard Henderson
Python testing fixes for 6.2 A few more fixes to help eliminate race conditions from device-crash-test, along with a fix that allows the SCM_RIGHTS functionality to work on hosts that only have Python 3.6. If this is too much this late in the RC process, I'd advocate for at least patch 7/7 by itself. # gpg: Signature made Tue 23 Nov 2021 03:37:17 AM CET # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] * tag 'python-pull-request' of https://gitlab.com/jsnow/qemu: python/aqmp: fix send_fd_scm for python 3.6.x scripts/device-crash-test: Use a QMP timeout python/machine: handle "fast" QEMU terminations python/machine: move more variable initializations to _pre_launch python/machine: add instance disambiguator to default nickname python/machine: remove _remove_monitor_sockfile property python/machine: add @sock_dir property Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23linux-user/signal.c: Create a common rewind_if_in_safe_syscallWarner Losh
All instances of rewind_if_in_safe_syscall are the same, differing only in how the instruction point is fetched from the ucontext and the size of the registers. Use host_signal_pc and new host_signal_set_pc interfaces to fetch the pointer to the PC and adjust if needed. Delete all the old copies of rewind_if_in_safe_syscall. Acked-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211113045603.60391-3-imp@bsdimp.com> [rth: include safe-syscall.h, simplify ifdefs] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23linux-user: Add host_signal_set_pc to set pc in mcontextWarner Losh
Add a new function host_signal_set_pc to set the next pc in an mcontext. The caller should ensure this is a valid PC for execution. Acked-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Warner Losh <imp@bsdimp.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20211113045603.60391-2-imp@bsdimp.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-23Merge tag 'pull-target-arm-20211122-1' of ↵Richard Henderson
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * drop spurious bump of ITS vmstate version fields # gpg: Signature made Mon 22 Nov 2021 07:43:19 PM CET # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] * tag 'pull-target-arm-20211122-1' of https://git.linaro.org/people/pmaydell/qemu-arm: hw/intc/arm_gicv3_its: Revert version increments in vmstate_its Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-11-22python/aqmp: fix send_fd_scm for python 3.6.xJohn Snow
3.6 doesn't play keepaway with the socket object, so we don't need to go fishing for it on this version. In fact, so long as 'sendmsg' is still available, it's probably preferable to just use that method and only go fishing for forbidden details when we absolutely have to. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20211118204620.1897674-8-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-11-22scripts/device-crash-test: Use a QMP timeoutJohn Snow
Despite all the previous fixes, it's still possible for device-crash-test to wedge itself in the case that QEMU terminates *so quickly* that it doesn't even begin a connection attempt to our QMP client. Python will just joyfully wait ad infinitum for a connection that will now never arrive. The real fix is to use asyncio to simultaneously poll both the health of the launched process AND the connection attempt. That's quite a bit more invasive than just setting a connection timeout, though. Do the very simplest thing for now. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20211118204620.1897674-7-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-11-22python/machine: handle "fast" QEMU terminationsJohn Snow
In the case that the QEMU process actually launches -- but then dies so quickly that we can't establish a QMP connection to it -- QEMUMachine currently calls _post_shutdown() assuming that it never launched the VM process. This isn't true, though: it "merely" may have failed to establish a QMP connection and the process is in the middle of its own exit path. If we don't wait for the subprocess, the caller may get a bogus `None` return for .exitcode(). This behavior was observed from device-crash-test; after the switch to Async QMP, the timings were changed such that it was now seemingly possible to witness the failure of "vm.launch()" *prior* to the exitcode becoming available. The semantic of the `_launched` property is changed in this patch. Instead of representing the condition "launch() executed successfully", it will now represent "has forked a child process successfully". This way, wait() when called in the exit path won't become a no-op. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20211118204620.1897674-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-11-22python/machine: move more variable initializations to _pre_launchJohn Snow
No need to clear them only to set them later. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20211118204620.1897674-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-11-22python/machine: add instance disambiguator to default nicknameJohn Snow
If you create two instances of QEMUMachine(), they'll both create the same nickname by default -- which is not that helpful. Luckily, they'll both create unique temporary directories ... but due to user configuration, they may share logging and sockfile directories, meaning two instances can collide. The Python logging will also be quite confusing, with no differentiation between the two instances. Add an instance disambiguator (The memory address of the instance) to the default nickname to foolproof this in all cases. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20211118204620.1897674-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-18 20:05:48 +0000