These variants take a float64 as input, compute the result to
infinite precision (as we do with FloatParts), round the result
to the precision and dynamic range of float32, and then return
the result in the format of float64.
This is the operation PowerPC requires for its float32 operations.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-28-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Now that vxsqrt and vxsnan are computed directly by softfloat,
we don't need to recompute it. Split out float_invalid_op_sqrt
to be used in several places. This fixes VSX_SQRT, which did
not order its tests correctly to eliminate NaN with sign set.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-25-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
target/ppc: Do not call do_float_check_status from do_fmadd
We will process flags other than in valid in helper_float_check_status,
which is invoked after the writeback to FRT.
Fixes a bug in which FRT is not written when OE/UE/XE are enabled.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-21-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Now that vximz, vxisi, and vxsnan are computed directly by
softfloat, we don't need to recompute it. This replaces the
separate float{32,64}_maddsub_update_excp functions with a
single float_invalid_op_madd function.
Fix VSX_MADD by passing sfprf to float_invalid_op_madd,
whereas the previous *_maddsub_update_excp assumed it true.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-19-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
In GEN_FLOAT_B, we called helper_reset_fpstatus immediately
before calling helper_fri*. Therefore get_float_exception_flags
is known to be zero, and this code can be simplified.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-17-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211119160502.17432-16-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
There's no reason the callers can't tail call to one function.
Leave it up to the compiler either way.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211119160502.17432-15-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
target/ppc: Move float_check_status from FPU_FCTI to translate
Fixes a bug in which e.g XE enabled causes inexact to be raised
before the writeback to the architectural register.
All of the users of GEN_FLOAT_B either set set_fprf, or are one
of the convert-to-integer instructions that require this behaviour.
Split out the two gen_helper_* calls in gen_compute_fprf_float64
and protect only the first with set_fprf.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20211119160502.17432-12-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
softfloat: Extend float_exception_flags to 16 bits
We will shortly have more than 8 bits of exceptions.
Repack the existing flags into low bits and reformat to hex.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211119160502.17432-2-richard.henderson@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Leonardo Garcia [Fri, 17 Dec 2021 16:57:13 +0000 (17:57 +0100)]
docs: rSTify ppc-spapr-hcalls.txt
Signed-off-by: Leonardo Garcia <lagarcia@br.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
[ clg: - replaced lingua by terminology
- add a new line at EOF ]
Message-Id: <e20319dcf0ec37bedd915c740c3813eb0e58ead4.1638982486.git.lagarcia@br.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Leonardo Garcia [Fri, 17 Dec 2021 16:57:13 +0000 (17:57 +0100)]
docs: Introducing pseries documentation.
The purpose of this document is to substitute the content currently
available in the QEMU wiki at [0]. This initial version does contain
some additional content as well. Whenever this documentation gets
upstream and is reflected in [1], the QEMU wiki will be edited to point
to this documentation, so that we only need to keep it updated in one
place.
This happens because we're using fdt_property_string(), which is a
sequential write function that is supposed to be used when we're
building a new FDT, in a case where read/writing into an existing FDT.
Fix it by using fdt_setprop_string() instead.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20211207094858.744386-1-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
ppc/pnv.c: add a friendly warning when accel=kvm is used
If one tries to use -machine powernv9,accel=kvm in a Power9 host, a
cryptic error will be shown:
qemu-system-ppc64: Register sync failed... If you're using kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
Appending '-cpu host' will throw another error:
qemu-system-ppc64: invalid chip model 'host' for powernv9 machine
The root cause is that in IBM PowerPC we have different specs for the bare-metal
and the guests. The bare-metal follows OPAL, the guests follow PAPR. The kernel
KVM modules presented in the ppc kernels implements PAPR. This means that we
can't use KVM accel when using the powernv machine, which is the emulation of
the bare-metal host.
All that said, let's give a more informative error in this case.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20211130133153.444601-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
pci-host: Allow extended config space access for PowerNV PHB4 model
The PCIe extended configuration space on the device is not currently
accessible to the host. if by default, it is still inaccessible for
conventional for PCIe buses, add the current flag
PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended
config space access.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211109145053.43524-1-clombard@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
After the endianness change done in the previous patch, we can verify in
both a a Power 9 little-endian host and in a Power 8 big-endian host
that this test is now passing:
$ QTEST_QEMU_BINARY=./ppc64-softmmu/qemu-system-ppc64 ./tests/qtest/ivshmem-test -m slow
/ppc64/ivshmem/single: OK
/ppc64/ivshmem/hotplug: OK
/ppc64/ivshmem/memdev: OK
/ppc64/ivshmem/pair: OK
/ppc64/ivshmem/server: OK
Let's keep it that way by officially enabling it for ppc64.
Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211124092948.335389-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
The ivshmem device, as with most PCI devices, uses little endian byte
order. However, the endianness of its mmio_ops is marked as
DEVICE_NATIVE_ENDIAN. This presents not only the usual problems with big
endian hosts but also with PowerPC little endian hosts as well, since
the Power architecture in QEMU uses big endian hardware (XIVE controller,
PCI Host Bridges, etc) even if the host is in little endian byte order.
As it is today, the IVPosition of the device will be byte swapped when
running in Power BE and LE. This can be seen by changing the existing
qtest 'ivshmem-test' to run in ppc64 hosts and printing the IVPOSITION
regs in test_ivshmem_server() right after the VM ids assert. For x86_64
the VM id values read are '0' and '1', for ppc64 (tested in a Power8
RHEL 7.9 BE server) and ppc64le (tested in a Power9 RHEL 8.6 LE server)
the ids will be '0' and '0x1000000'.
Change this device to LITTLE_ENDIAN fixes the issue for Power hosts of
both endianness, and every other big-endian architecture that might use
this device, without impacting x86 users.
Fixes: cb06608e17f8 ("ivshmem: convert to memory API")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/168 Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211124092948.335389-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Matheus Ferst [Fri, 17 Dec 2021 16:57:13 +0000 (17:57 +0100)]
target/ppc: Implement Vector Mask Move insns
Implement the following PowerISA v3.1 instructions:
mtvsrbm: Move to VSR Byte Mask
mtvsrhm: Move to VSR Halfword Mask
mtvsrwm: Move to VSR Word Mask
mtvsrdm: Move to VSR Doubleword Mask
mtvsrqm: Move to VSR Quadword Mask
mtvsrbmi: Move to VSR Byte Mask Immediate
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br>
Message-Id: <20211203194229.746275-4-matheus.ferst@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
target/ppc: ppc_store_fpscr doesn't update bits 0 to 28 and 52
This commit fixes the difference reported in the bug in the reserved
bit 52, it does this by adding this bit to the mask of bits to not be
directly altered in the ppc_store_fpscr function (the hardware used to
compare to QEMU was a Power9).
The bits 0 to 27 were also added to the mask, as they are marked as
reserved in the PowerISA and bit 28 is a reserved extension of the DRN
field (bits 29:31) but can't be set using mtfsfi, while the other DRN
bits may be set using mtfsfi instruction, so bit 28 was also added to
the mask.
Although this is a difference reported in the bug, since it's a reserved
bit it may be a "don't care" case, as put in the bug report. Looking at
the ISA it doesn't explicitly mention this bit can't be set, like it
does for FEX and VX, so I'm unsure if this is necessary.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/266 Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br>
Message-Id: <20211201163808.440385-4-lucas.araujo@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
mtfsf, mtfsfi and mtfsb1 instructions call helper_float_check_status
after updating the value of FPSCR, but helper_float_check_status
checks fp_status and fp_status isn't updated based on FPSCR and
since the value of fp_status is reset earlier in the instruction,
it's always 0.
Because of this helper_float_check_status would change the FI bit to 0
as this bit checks if the last operation was inexact and
float_flag_inexact is always 0.
These instructions also don't throw exceptions correctly since
helper_float_check_status throw exceptions based on fp_status.
This commit created a new helper, helper_fpscr_check_status that checks
FPSCR value instead of fp_status and checks for a larger variety of
exceptions than do_float_check_status.
Since fp_status isn't used, gen_reset_fpstatus() was removed.
The hardware used to compare QEMU's behavior to was a Power9.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br>
Message-Id: <20211201163808.440385-2-lucas.araujo@eldorado.org.br> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Peter Maydell [Fri, 17 Dec 2021 16:57:12 +0000 (17:57 +0100)]
hw/ppc/mac.h: Remove MAX_CPUS macro
The mac.h header defines a MAX_CPUS macro. This is confusingly named,
because it suggests it's a generic setting, but in fact it's used
by only the g3beige and mac99 machines. It's also using a single
macro for two values which aren't inherently the same -- if one
of these two machines was updated to support SMP configurations
then it would want a different max_cpus value to the other.
Since the macro is used in only two places, just expand it out
and get rid of it. If hypothetical future work to support SMP
in these boards needs a compile-time-known limit on the number
of CPUs, we can give it a suitable name at that point.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20211105184216.120972-1-peter.maydell@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Stefan Hajnoczi [Wed, 8 Dec 2021 15:22:46 +0000 (15:22 +0000)]
block/nvme: fix infinite loop in nvme_free_req_queue_cb()
When the request free list is exhausted the coroutine waits on
q->free_req_queue for the next free request. Whenever a request is
completed a BH is scheduled to invoke nvme_free_req_queue_cb() and wake
up waiting coroutines.
2. nvme_free_req_queue_cb() wakes up the coroutine:
while (qemu_co_enter_next(&q->free_req_queue, &q->lock)) {
^--- infinite loop when free_req_head == -1
}
nvme_free_req_queue_cb() and the coroutine form an infinite loop when
q->free_req_head == -1. Fix this by checking q->free_req_head in
nvme_free_req_queue_cb(). If the free request list is exhausted, don't
wake waiting coroutines. Eventually an in-flight request will complete
and the BH will be scheduled again, guaranteeing forward progress.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20211208152246.244585-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Damien Hedde [Tue, 7 Dec 2021 09:44:27 +0000 (10:44 +0100)]
gicv3: fix ICH_MISR's LRENP computation
According to the "Arm Generic Interrupt Controller Architecture
Specification GIC architecture version 3 and 4" (version G: page 345
for aarch64 or 509 for aarch32):
LRENP bit of ICH_MISR is set when ICH_HCR.LRENPIE==1 and
ICH_HCR.EOIcount is non-zero.
When only LRENPIE was set (and EOI count was zero), the LRENP bit was
wrongly set and MISR value was wrong.
As an additional consequence, if an hypervisor set ICH_HCR.LRENPIE,
the maintenance interrupt was constantly fired. It happens since patch 9cee1efe92 ("hw/intc: Set GIC maintenance interrupt level to only 0 or 1")
which fixed another bug about maintenance interrupt (most significant
bits of misr, including this one, were ignored in the interrupt trigger).
Fixes: 83f036fe3d ("hw/intc/arm_gicv3: Add accessors for ICH_ system registers") Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20211207094427.3473-1-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Merge tag 'pull-tcg-20211207' of https://gitlab.com/rth7680/qemu into staging
Fix stack spills for arm neon.
# gpg: Signature made Tue 07 Dec 2021 06:33:57 AM PST
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [ultimate]
* tag 'pull-tcg-20211207' of https://gitlab.com/rth7680/qemu:
tcg/arm: Reduce vector alignment requirement for NEON
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg/arm: Reduce vector alignment requirement for NEON
With arm32, the ABI gives us 8-byte alignment for the stack.
While it's possible to realign the stack to provide 16-byte alignment,
it's far easier to simply not encode 16-byte alignment in the
VLD1 and VST1 instructions that we emit.
Remove the assertion in temp_allocate_frame, limit natural alignment
to the provided stack alignment, and add a comment.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1999878 Reported-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210912174925.200132-1-richard.henderson@linaro.org>
Message-Id: <20211206191335.230683-2-richard.henderson@linaro.org>
Merge tag 'mips-20211206' of https://github.com/philmd/qemu into staging
MIPS fixes
- Do not emit SD instruction on 32-bit CPU (Jiaxun Yang)
- Correctly catch load_elf() errors on Boston board (Jiaxun Yang)
- Revert bogus CLI fix for ISA VGA devices (Alex Bennée)
# gpg: Signature made Mon 06 Dec 2021 03:03:24 AM PST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full]
* tag 'mips-20211206' of https://github.com/philmd/qemu:
Revert "vga: don't abort when adding a duplicate isa-vga device"
hw/mips/boston: Fix load_elf() error detection
hw/mips/bootloader: Fix write_ulong()
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Mark Mielke [Thu, 2 Dec 2021 16:26:51 +0000 (11:26 -0500)]
virtio-blk: Fix clean up of host notifiers for single MR transaction.
The code that introduced "virtio-blk: Configure all host notifiers in
a single MR transaction" introduced a second loop variable to perform
cleanup in second loop, but mistakenly still refers to the first
loop variable within the second loop body.
Fixes: d0267da61489 ("virtio-blk: Configure all host notifiers in a single MR transaction") Signed-off-by: Mark Mielke <mark.mielke@gmail.com>
Message-id: CALm7yL08qarOu0dnQkTN+pa=BSRC92g31YpQQNDeAiT4yLZWQQ@mail.gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The check is bogus as it ends up finding itself and falling over.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/733 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211206095209.2332376-1-alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Merge tag 'ide-pull-request' of https://gitlab.com/jsnow/qemu into staging
Pull request
# gpg: Signature made Wed 01 Dec 2021 10:17:38 PM PST
# gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E
# gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full]
* tag 'ide-pull-request' of https://gitlab.com/jsnow/qemu:
tests/qtest/fdc-test: Add a regression test for CVE-2021-20196
hw/block/fdc: Kludge missing floppy drive to fix CVE-2021-20196
hw/block/fdc: Extract blk_create_empty_drive()
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tests/qtest/fdc-test: Add a regression test for CVE-2021-20196
Without the previous commit, when running 'make check-qtest-i386'
with QEMU configured with '--enable-sanitizers' we get:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==287878==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000344
==287878==The signal is caused by a WRITE memory access.
==287878==Hint: address points to the zero page.
#0 0x564b2e5bac27 in blk_inc_in_flight block/block-backend.c:1346:5
#1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5
#2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11
#3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17
#4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9
#5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9
Add the reproducer for CVE-2021-20196.
Suggested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20211124161536.631563-4-philmd@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
hw/block/fdc: Kludge missing floppy drive to fix CVE-2021-20196
Guest might select another drive on the bus by setting the
DRIVE_SEL bit of the DIGITAL OUTPUT REGISTER (DOR).
The current controller model doesn't expect a BlockBackend
to be NULL. A simple way to fix CVE-2021-20196 is to create
an empty BlockBackend when it is missing. All further
accesses will be safely handled, and the controller state
machines keep behaving correctly.
Cc: qemu-stable@nongnu.org Fixes: CVE-2021-20196 Reported-by: Gaoning Pan (Ant Security Light-Year Lab) <pgn@zju.edu.cn> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20211124161536.631563-3-philmd@redhat.com BugLink: https://bugs.launchpad.net/qemu/+bug/1912780
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/338 Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
We are going to re-use this code in the next commit,
so extract it as a new blk_create_empty_drive() function.
Inspired-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20211124161536.631563-2-philmd@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Merge tag 'pull-ppc-20211129' of https://github.com/legoater/qemu into staging
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>
Leandro Lupori [Mon, 29 Nov 2021 18:57:51 +0000 (15:57 -0300)]
target/ppc: fix Hash64 MMU update of PTE bit R
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>
Merge tag 'pull-for-6.2-291121-1' of https://github.com/stsquad/qemu into 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>
Juro Bystricky [Mon, 29 Nov 2021 14:09:32 +0000 (14:09 +0000)]
tests/plugin/syscall.c: fix compiler warnings
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>
Alex Bennée [Mon, 29 Nov 2021 14:09:29 +0000 (14:09 +0000)]
gdbstub: handle a potentially racing TaskState
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>
Alex Bennée [Mon, 29 Nov 2021 14:09:28 +0000 (14:09 +0000)]
plugins/meson.build: fix linker issue with weird paths
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>
Alex Bennée [Mon, 29 Nov 2021 14:09:27 +0000 (14:09 +0000)]
tests/avocado: fix tcg_plugin mem access count test
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>
Alex Bennée [Mon, 29 Nov 2021 14:09:26 +0000 (14:09 +0000)]
accel/tcg: suppress IRQ check for special TBs
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>
Alex Bennée [Mon, 29 Nov 2021 14:09:25 +0000 (14:09 +0000)]
accel/tcg: introduce CF_NOIRQ
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>
Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu 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>
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>
Jason Wang [Mon, 29 Nov 2021 03:36:18 +0000 (11:36 +0800)]
intel-iommu: ignore leaf SNP bit in scalable mode
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>
Jason Wang [Mon, 29 Nov 2021 03:08:41 +0000 (11:08 +0800)]
virtio-balloon: correct used length
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>
Jason Wang [Mon, 29 Nov 2021 03:08:40 +0000 (11:08 +0800)]
virtio-balloon: process all in sgs for free_page_vq
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>
Merge tag 'pull-target-arm-20211129' of 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>
Peter Maydell [Fri, 26 Nov 2021 16:39:15 +0000 (16:39 +0000)]
hw/intc/arm_gicv3: fix handling of LPIs in list registers
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>
Eugenio Pérez [Thu, 25 Nov 2021 10:16:13 +0000 (11:16 +0100)]
vdpa: Add dummy receive callback
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>
Laurent Vivier [Thu, 18 Nov 2021 13:32:23 +0000 (14:32 +0100)]
failover: fix unplug pending detection
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>
Cindy Lu [Tue, 9 Nov 2021 02:37:44 +0000 (10:37 +0800)]
virtio-mmio : fix the crash in the vm shutdown
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>
Peter Maydell [Fri, 26 Nov 2021 16:39:14 +0000 (16:39 +0000)]
hw/intc/arm_gicv3: Add new gicv3_intid_is_special() function
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>
Peter Maydell [Wed, 24 Nov 2021 20:20:05 +0000 (20:20 +0000)]
hw/intc/arm_gicv3: Update cached state after LPI state changes
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
projects / qemu-xen.git / log