Update SymQEMU to v8.2.1 #48
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ICC_PMR_ELx and ICV_PMR_ELx bit masks returned from
ic{c,v}_fullprio_mask should technically also remove any
bit above 7 as these are marked reserved (read 0) and should
therefore should not be written as anything other than 0.
This was noted during a run of a proprietary test system and
discused on the mailing list [1] and initially thought not to
be an issue due to RES0 being technically allowed to be
written to and read back as long as the implementation does
not use the RES0 bits. It is very possible that the values
are used in comparison without masking, as pointed out by
Peter in [2], if (cs->hppi.prio >= cs->icc_pmr_el1) may well
do the wrong thing.
Masking these values in ic{c,v}_fullprio_mask() should fix
this and prevent any future problems with playing with the
values.
[1]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00607.html
[2]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00737.html
Signed-off-by: Ben Dooks <[email protected]>
Message-id: [email protected]
Suggested-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Perform the loop increment unconditionally, not nested within the predication. Cc: [email protected] Fixes: 3916841 ("target/arm: Implement FMOPA, FMOPS (widening)") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1985 Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>
Constify MachineClass::valid_cpu_types[i], as suggested by Richard Henderson. Suggested-by: Richard Henderson <[email protected]> Signed-off-by: Gavin Shan <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] [PMD: Constify HPPA machines, restrict valid_cpu_types to machine_class_init() handlers] Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Peter Maydell <[email protected]>
Both 'netduinoplus2' and 'olimex-stm32-h405' machines ignore the CPU type requested by the command line. This might confuse users, since the following will create a machine with a Cortex-M4 CPU: $ qemu-system-aarch64 -M netduinoplus2 -cpu cortex-r5f Set the MachineClass::valid_cpu_types field (introduced in commit c9cf636 "machine: Add a valid_cpu_types property"). Remove the now unused MachineClass::default_cpu_type field. We now get: $ qemu-system-aarch64 -M netduinoplus2 -cpu cortex-r5f qemu-system-aarch64: Invalid CPU type: cortex-r5f-arm-cpu The valid types are: cortex-m4-arm-cpu Since the SoC family can only use Cortex-M4 CPUs, hard-code the CPU type name at the SoC level, removing the QOM property entirely. Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>
The 'netduino2' machine ignores the CPU type requested by the command line. This might confuse users, since the following will create a machine with a Cortex-M3 CPU: $ qemu-system-arm -M netduino2 -cpu cortex-a9 Set the MachineClass::valid_cpu_types field (introduced in commit c9cf636 "machine: Add a valid_cpu_types property"). Remove the now unused MachineClass::default_cpu_type field. We now get: $ qemu-system-arm -M netduino2 -cpu cortex-a9 qemu-system-arm: Invalid CPU type: cortex-a9-arm-cpu The valid types are: cortex-m3-arm-cpu Since the SoC family can only use Cortex-M3 CPUs, hard-code the CPU type name at the SoC level, removing the QOM property entirely. Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>
The 'stm32vldiscovery' machine ignores the CPU type requested by the command line. This might confuse users, since the following will create a machine with a Cortex-M3 CPU: $ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1 Set the MachineClass::valid_cpu_types field (introduced in commit c9cf636 "machine: Add a valid_cpu_types property"). Remove the now unused MachineClass::default_cpu_type field. We now get: $ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1 qemu-system-aarch64: Invalid CPU type: neoverse-n1-arm-cpu The valid types are: cortex-m3-arm-cpu Since the SoC family can only use Cortex-M3 CPUs, hard-code the CPU type name at the SoC level, removing the QOM property entirely. Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>
Both i.MX25 and i.MX6 SoC models ignore the Error argument when setting the PHY number. Pick &error_abort which is the error used by the i.MX7 SoC (see commit 1f7197d "ability to change the FEC PHY on i.MX7 processor"). Fixes: 74c1330 ("ability to change the FEC PHY on i.MX25 processor") Fixes: a9c167a ("ability to change the FEC PHY on i.MX6 processor") Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>
On LoongArch host, we got an Aborted from tcg_out_mov(). qemu-x86_64 configure with '--enable-debug'. > (gdb) b /home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc:312 > Breakpoint 1 at 0x2576f0: file /home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc, line 312. > (gdb) run hello [...] > Thread 1 "qemu-x86_64" hit Breakpoint 1, tcg_out_mov (s=0xaaaae91760 <tcg_init_ctx>, type=TCG_TYPE_V128, ret=TCG_REG_V2, > arg=TCG_REG_V0) at /home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc:312 > 312 g_assert_not_reached(); > (gdb) bt > #0 tcg_out_mov (s=0xaaaae91760 <tcg_init_ctx>, type=TCG_TYPE_V128, ret=TCG_REG_V2, arg=TCG_REG_V0) > at /home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc:312 > eurecom-s3#1 0x000000aaaad0fee0 in tcg_reg_alloc_mov (s=0xaaaae91760 <tcg_init_ctx>, op=0xaaaaf67c20) at ../tcg/tcg.c:4632 > eurecom-s3#2 0x000000aaaad142f4 in tcg_gen_code (s=0xaaaae91760 <tcg_init_ctx>, tb=0xffe8030340 <code_gen_buffer+197328>, > pc_start=4346094) at ../tcg/tcg.c:6135 [...] > (gdb) c > Continuing. > ** > ERROR:/home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc:312:tcg_out_mov: code should not be reached > Bail out! ERROR:/home1/gaosong/code/qemu/tcg/loongarch64/tcg-target.c.inc:312:tcg_out_mov: code should not be reached > > Thread 1 "qemu-x86_64" received signal SIGABRT, Aborted. > 0x000000fff7b1c390 in raise () from /lib64/libc.so.6 > (gdb) q Fixes: 16288de ("tcg/loongarch64: Lower basic tcg vec ops to LSX") Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Song Gao <[email protected]> Message-Id: <[email protected]>
Coverity warns that "i2c_bus_busy(i2c->busses[i]) << i" might overflow because the expression is evaluated using 32-bit arithmetic and then used in a context expecting a uint64_t. While we are at it, introduce a PNV_I2C_MAX_BUSSES constant and check the number of busses at realize time. Fixes: Coverity CID 1523918 Cc: Glenn Miles <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Glenn Miles <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]>
The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the source vector is incorrectly converted to 0, 0x80000000, or 0x8000000000000000 instead of the expected value if a preceding source floating point value from the same source vector was a NaN. The bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros in target/ppc/fpu_helper.c was introduced with commit c3f2425. This patch also adds a new vsx_f2i_nan test in tests/tcg/ppc64 that checks that the VSX xvcvspsxws, xvcvspuxws, xvcvspsxds, xvcvspuxds, xvcvdpsxws, xvcvdpuxws, xvcvdpsxds, and xvcvdpuxds instructions correctly convert non-NaN floating point values to integer values if the source vector contains NaN floating point values. Fixes: c3f2425 ("target/ppc: Clear fpstatus flags on helpers missing it") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1941 Signed-off-by: John Platts <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]>
The PNV I2C engines for power9 and power10 were being assigned a base XSCOM address that was off by one I2C engine's address range such that engine 0 had engine 1's address and so on. The xscom address assignment was being based on the device tree engine numbering, which starts at 1. Rather than changing the device tree numbering to start with 0, the addressing was changed to be based on the existing device tree numbers minus one. Fixes: 1ceda19 ("ppc/pnv: Connect PNV I2C controller to powernv10) Signed-off-by: Glenn Miles <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]>
The PNV I2C Controller was clearing the status register after a reset without repopulating the "upper threshold for I2C ports", "Command Complete" and the SCL/SDA input level fields. Fixed this for resets caused by a system reset as well as from writing to the "Immediate Reset" register. Fixes: 263b81e ("ppc/pnv: Add an I2C controller model") Signed-off-by: Glenn Miles <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]>
Recently MemReentrancyGuard was added to DeviceState to record that the device is engaging in I/O. The network device backend needs to update it when delivering a packet to a device. In preparation for such a change, add MemReentrancyGuard * as a parameter of qemu_new_nic(). Signed-off-by: Akihiko Odaki <[email protected]> Reviewed-by: Alexander Bulekov <[email protected]> Signed-off-by: Jason Wang <[email protected]>
Recently MemReentrancyGuard was added to DeviceState to record that the device is engaging in I/O. The network device backend needs to update it when delivering a packet to a device. This implementation follows what bottom half does, but it does not add a tracepoint for the case that the network device backend started delivering a packet to a device which is already engaging in I/O. This is because such reentrancy frequently happens for qemu_flush_queued_packets() and is insignificant. Fixes: CVE-2023-3019 Reported-by: Alexander Bulekov <[email protected]> Signed-off-by: Akihiko Odaki <[email protected]> Acked-by: Alexander Bulekov <[email protected]> Signed-off-by: Jason Wang <[email protected]>
In net_cleanup() we only need to delete the netdevs, as those may have state which outlives Qemu when it exits, and thus may actually need to be cleaned up on exit. The nics, on the other hand, are owned by the device which created them. Most devices don't bother to clean up on exit because they don't have any state which will outlive Qemu... but XenBus devices do need to clean up their nodes in XenStore, and do have an exit handler to delete them. When the XenBus exit handler destroys the xen-net-device, it attempts to delete its nic after net_cleanup() had already done so. And crashes. Fix this by only deleting netdevs as we walk the list. As the comment notes, we can't use QTAILQ_FOREACH_SAFE() as each deletion may remove *multiple* entries, including the "safely" saved 'next' pointer. But we can store the *previous* entry, since nics are safe. Signed-off-by: David Woodhouse <[email protected]> Reviewed-by: Paul Durrant <[email protected]> Signed-off-by: Jason Wang <[email protected]>
Commit 1bec1cc ("ui/console: allow to override the default VC") changed the behaviour of the "-display none" option, so that it now creates a QEMU monitor on the terminal. "-display none" should not be tangled up with whether we create a monitor or a serial terminal; it should purely and only disable the graphical window. Changing its behaviour like this breaks command lines which, for example, use semihosting for their output and don't want a graphical window, as they now get a monitor they never asked for. It also breaks the command line we document for Xen in docs/system/i386/xen.html: $ ./qemu-system-x86_64 --accel kvm,xen-version=0x40011,kernel-irqchip=split \ -display none -chardev stdio,mux=on,id=char0,signal=off -mon char0 \ -device xen-console,chardev=char0 -drive file=${GUEST_IMAGE},if=xen qemu-system-x86_64: cannot use stdio by multiple character devices qemu-system-x86_64: could not connect serial device to character backend 'stdio' When qemu is compiled without PIXMAN, by default the serials aren't muxed with the monitor anymore on stdio. The serials are redirected to "null" instead, and the monitor isn't set up. Fixes: commit 1bec1cc ("ui/console: allow to override the default VC") Signed-off-by: Marc-André Lureau <[email protected]> Tested-by: Peter Maydell <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Tested-by: David Woodhouse <[email protected]> Reviewed-by: David Woodhouse <[email protected]>
Those display have their own implementation of "vc" chardev, which doesn't use pixman. They also don't implement the width/height/cols/rows options, so qemu_display_get_vc() should return a compatible argument. This patch was meant to be with the pixman series, when the "vc" field was introduced. It fixes a regression where VC are created on the tty (or null) instead of the display own "vc" implementation. Signed-off-by: Marc-André Lureau <[email protected]> Acked-by: Thomas Huth <[email protected]>
When display is "none", we may still have remote displays (I think it would be simpler if VNC/Spice were regular display btw). Return the default VC then, and set them up to fix a regression when using remote display and it used the TTY instead. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1989 Fixes: commit 1bec1cc ("ui/console: allow to override the default VC") Reported-by: German Maglione <[email protected]> Signed-off-by: Marc-André Lureau <[email protected]> Acked-by: Thomas Huth <[email protected]>
We should also consider -display vnc= as setting up a remote display, and not attempt to add another default one. The display_remote++ in qemu_setup_display() isn't necessary at this point, but is there for completeness and further usages of the variable. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1988 Fixes: commit 484629f ("vl: simplify display_remote logic ") Signed-off-by: Marc-André Lureau <[email protected]>
In the minimal pixman API stub that is used when the real pixman dependency is missing a NULL dereference happens when virtio-gpu-rutabaga allocates a pixman image with bits = NULL and rowstride_bytes = zero. A buffer of rowstride_bytes * height is allocated which is NULL. However, in that scenario pixman calculates a new stride value based on given width, height and format size. This commit adds a helper function that performs the same logic as pixman. Signed-off-by: Manos Pitsidianakis <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]>
…into staging fixes tcg_out_mov aborted. # -----BEGIN PGP SIGNATURE----- # # iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZVwXJgAKCRBAov/yOSY+ # 30HKBAC4+3oAaMqRDEBTlYT0oHmU3IVRv7Pkuht72YZ57qQwjq21jMpxRdeuAAT2 # McGzDIH/IbF0qG1HBako00jiwgGpx90aBU0KwOVgBjyjvUK2VXE268UoRs+WYVG/ # 7ljOHEnpvwJVTquAtDNFZIw0EFwiF75MP2rKvrSG8KmmrSu4hg== # =oHNA # -----END PGP SIGNATURE----- # gpg: Signature made Mon 20 Nov 2023 21:34:14 EST # gpg: using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF # gpg: Good signature from "Song Gao <[email protected]>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: B8FF 1DA0 D2FD CB2D A09C 6C2C 40A2 FFF2 3926 3EDF * tag 'pull-loongarch-20231121' of https://gitlab.com/gaosong/qemu: tcg/loongarch64: Fix tcg_out_mov() Aborted Signed-off-by: Stefan Hajnoczi <[email protected]>
…o staging ppc queue: * PNV I2C fixes * VSX instruction fix when converting floating point to integer values # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmVcZ18ACgkQUaNDx8/7 # 7KG1GBAAopdIWc33pY1kaJlHxXDDtTxShWT384r62unPO0vaDtvmlLBvD0kTRIzk # E6OcWeGS/L2D03nI127o5Y677koL20TlOpsR4fZdOwbQUSSVTMsLN5m8Rqvu4Ptx # zA8t/Oio+RTxkZ1SHRuEQNC5EWzFklm5R95zyvLEAbMdJ44thlXyo9KgWe8XoBBV # tkreEzWvv4F4Nf7nZYnxvOIHsi/8No0bMMjBNGC/v+svpayuaWmsCP4/4vmVRYRP # 28R6uMooo9xu0X6oBzqbAV6y6XFSP8pwsvVPd1yAbFhS3w2qw18VpWoMUl2UkVGx # ZNNHjt3HPtGAEtnWAdvzVS8sFi929pHf2v5/h8gEhfZ2e4NVS1zJj3K3OqJgWfEB # XjiIO4NF4gnbXKIlvZX8m5RqdtxbdKx7BVmJtlzJd7IDERRLe0cNSCZ06s/GcICi # AHtxhyA5GGWs2HDQwkOimwDOholjjVbz/sIcHLCpm/jyxcdk9VwE6hBO/9nTcntg # IaQ/kWHlbQgTNXNuFDBwiOMuEQ5G4bb6sdqH+CWZU/owFqgXHIlki7oneX6SB09T # GUyVwScLWlspCJRpX/y4ubyfGB3ZqAQ9REita4YIMveDvNU83LS344MRrBpzQ+ZI # 1yCoHdBsNUkpr9dN/uwkjDSBlDoyWJ2TAgQHsprNUD04ChML7Fs= # =qx4p # -----END PGP SIGNATURE----- # gpg: Signature made Tue 21 Nov 2023 03:16:31 EST # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <[email protected]>" [unknown] # gpg: aka "Cédric Le Goater <[email protected]>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-ppc-20231121' of https://github.com/legoater/qemu: ppc/pnv: Fix PNV I2C invalid status after reset ppc/pnv: PNV I2C engines assigned incorrect XSCOM addresses target/ppc: Fix bugs in VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros ppc/pnv: Fix potential overflow in I2C model Signed-off-by: Stefan Hajnoczi <[email protected]>
… staging # -----BEGIN PGP SIGNATURE----- # Version: GnuPG v1 # # iQEcBAABAgAGBQJlXF+GAAoJEO8Ells5jWIROT0H/RGk64ds4eiKskWxwG9p8K8s # wCLdgadf/PRnKmMLR3i5gMX87Db83nUtX/tEgoNxSGuvTdK/JRuqf2oMLv5AOF27 # 6573reJW1z0Ho9Se5JW+DPI18hX7YzqwyJQ9QslGOSRXJb20O4iC2rICfI8MeFsW # tBTsBcJ4qwsVK4nqY/3Tz57lhZLF2xYZtdgvxS4urqg/PrcbAMq8SSB8cq7tjUUs # sgDMQQx4n/r8wlBJE1nnvF/NxtLyTj/rrS9J1rF7ztp/suea/vHxM3t9vTqjLSlY # TyFORcfSCK2edp2+QwARJTTU9FlnuSwf28Pnm2lMQjp5HjBO20bpCBIWGQl6C9A= # =T88Y # -----END PGP SIGNATURE----- # gpg: Signature made Tue 21 Nov 2023 02:43:02 EST # gpg: using RSA key EF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <[email protected]>" [full] # Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211 * tag 'net-pull-request' of https://github.com/jasowang/qemu: net: do not delete nics in net_cleanup() net: Update MemReentrancyGuard for NIC net: Provide MemReentrancyGuard * to qemu_new_nic() Signed-off-by: Stefan Hajnoczi <[email protected]>
…/pmaydell/qemu-arm into staging target-arm queue: * enable FEAT_RNG on Neoverse-N2 * hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ * Fix SME FMOPA (16-bit), BFMOPA * hw/core/machine: Constify MachineClass::valid_cpu_types[] * stm32f* machines: Report error when user asks for wrong CPU type * hw/arm/fsl-imx: Do not ignore Error argument # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmVchLYZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3kHMD/47tKxzrsXc6+V9esRQGi2H # 1hAgLBwglEdxLXokF+Di41sh/fvK7wYVXO/hiWlq+9h3kG3D/u1N5r1TdMPMUb9j # 4Sg3rOejn7nzkxVZ6MZ/K/1j84C9bfrt4sboVHZVRvWuvbiyuTuivEr4IqLYO4x3 # AIwhFMQ5gbNrmClZh/DBxj0keO13cp63Fg2JSSICdi+1Dw9rRXTyhJloMu1omeqc # k/BXzjSeNXpLSMyGWBR3uaPcJBaGC1xnz3Z1V7fUY1EYD2Cu1oo5lEZ9aNO5t30d # XW/qVGLa3b1Cb7WuEO247RnU3N2oZotozjFtdj/8IQoYWspM9RHyipEimUlegVdO # 3fpu8QGsN1ljNiwjdk0i6OwS7SGxcPtteFOaqEf/Yogj4EOKTn/Rx5TT4vJ5DhmI # 2w/9J15JWDIE1paNwecuFWbxCOOzSsOtSxzuyLSZDU3GlNfJ4zoF6YboROLYfejy # NXZABFhGd/0ykX7r0VY1GGYXUQ+akv6q+VDmVZCP9gMiRUiqmFPwMLMLlcuHb8G5 # 8UztN5SvOG2EYXj28Zx0BnGCNiGdI15rWMb0veqAtbnn3yEdltW3O475BAhZ0PB7 # OVpLWnXwmWURm/BGlwb1PH5s3kgWgzOebcBgcnCftwFQ8EedQAQDA5FmT+nK5SfV # VoOf89PngTubU6B3BOfeBw== # =thIa # -----END PGP SIGNATURE----- # gpg: Signature made Tue 21 Nov 2023 05:21:42 EST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "[email protected]" # gpg: Good signature from "Peter Maydell <[email protected]>" [full] # gpg: aka "Peter Maydell <[email protected]>" [full] # gpg: aka "Peter Maydell <[email protected]>" [full] # gpg: aka "Peter Maydell <[email protected]>" [unknown] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20231121' of https://git.linaro.org/people/pmaydell/qemu-arm: hw/arm/fsl-imx: Do not ignore Error argument hw/arm/stm32f100: Report error when incorrect CPU is used hw/arm/stm32f205: Report error when incorrect CPU is used hw/arm/stm32f405: Report error when incorrect CPU is used hw/core/machine: Constify MachineClass::valid_cpu_types[] target/arm: Fix SME FMOPA (16-bit), BFMOPA hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ target/arm: enable FEAT_RNG on Neoverse-N2 Signed-off-by: Stefan Hajnoczi <[email protected]>
… into staging UI: fixes for 8.2-rc1 # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmVciOwcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5VtiD/oDEfDSwTxkAD6TMFoY # n2XlzrElTAwYl0lgzzWHrdfoR2vtplIz3gK7u7MCa+rjUMowZbV3EBrMYDMoMWVU # NkuUeSZsHYuXjaKt/nCqnmxklmq0tGN9NOwdOD1V++u257qbkUSl2w7/K0xEohAs # NAeF3wWoCArQyjLD4K6LVsMe9IMrOP1VyGYrKBKQ91xpsuagkrjJt8RnO9MwodNs # 8a65HRKq7HPXvMqZF7v4HgZ2pa1vrWZv4zVTraUBHaW9XpdIoiAd2+WeshjuawhO # G6nQFpHVnQb8FBLrg+f5RItH+CjxhGvBa4DZmuGl1Y3s/fXN2N5QpUNIBqhgtE4P # fZ+iXIpyE8sqj0TThnusszgBGWKadVjQJ8nVEVTKHzXtIa2mthF2MyY/EgnR4zQa # 0H0YiE0SXYvoHxaErkvAfdt75OH0JBhiDcclFb1axFY2dhcgMuM7q7CR5HeO4fRd # UEvLb8K7TLPtBGBxH5Z9z+ecxN6jIIqetosbbWFAfuIbd+at64AMh2N/MYZk2Chy # 7E6ZGqNb8htOo2R5MitijpTm48vTs0gGjmyq7RHifG/yDHSUrPLrOgDkSC3IKY7y # Xc9aK6fqm0l6LTLDbmZhM/znoc/1TErw/T3S4rqky0wvFTpuhP29vwd8WuyQ1ZpS # viNCue6q0tScUz179wKEfYfyag== # =o08n # -----END PGP SIGNATURE----- # gpg: Signature made Tue 21 Nov 2023 05:39:40 EST # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "[email protected]" # gpg: Good signature from "Marc-André Lureau <[email protected]>" [full] # gpg: aka "Marc-André Lureau <[email protected]>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu: ui/pixman-minimal.h: fix empty allocation vl: add missing display_remote++ ui/console: fix default VC when there are no display ui: use "vc" chardev for dbus, gtk & spice-app vl: revert behaviour for -display none Signed-off-by: Stefan Hajnoczi <[email protected]>
If a Xen console is configured on the command line, do not add a default serial port. Signed-off-by: David Woodhouse <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Reviewed-by: Paul Durrant <[email protected]>
…ositive Coverity couldn't see that nr_existing was always going to be zero when qemu_xen_xs_directory() returned NULL in the ENOENT case (CID 1523906). Perhaps more to the point, neither could Peter at first glance. Improve the code to hopefully make it clearer to Coverity and human reviewers alike. Signed-off-by: David Woodhouse <[email protected]> Reviewed-by: Paul Durrant <[email protected]>
Legacy software contains a standard mechanism for generating a reset to a Serial ATA device - setting the SRST (software reset) bit in the Device Control register. Serial ATA has a more robust mechanism called COMRESET, also referred to as port reset. A port reset is the preferred mechanism for error recovery and should be used in place of software reset. Commit e2a5d9b ("hw/ide/ahci: simplify and document PxCI handling") improved the handling of PxCI, such that PxCI gets cleared after handling a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after receiving anything - even a FIS that failed to parse, which should NOT clear PxCI, so that you can see which command slot that caused an error). However, simply clearing PxCI after a non-NCQ, or NCQ command, is not enough, we also need to clear PxCI when receiving a SRST in the Device Control register. A legacy software reset is performed by the host sending two H2D FISes, the first H2D FIS asserts SRST, and the second H2D FIS deasserts SRST. The first H2D FIS will not get a D2H reply, and requires the FIS to have the C bit set to one, such that the HBA itself will clear the bit in PxCI. The second H2D FIS will get a D2H reply once the diagnostic is completed. The clearing of the bit in PxCI for this command should ideally be done in ahci_init_d2h() (if it was a legacy software reset that caused the reset (a COMRESET does not use a command slot)). However, since the reset value for PxCI is 0, modify ahci_reset_port() to actually clear PxCI to 0, that way we can avoid complex logic in ahci_init_d2h(). This fixes an issue for FreeBSD where the device would fail to reset. The problem was not noticed in Linux, because Linux uses a COMRESET instead of a legacy software reset by default. Fixes: e2a5d9b ("hw/ide/ahci: simplify and document PxCI handling") Reported-by: Marcin Juszkiewicz <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Tested-by: Marcin Juszkiewicz <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
While not all callers of blk_remove_bs() are correct in this respect, the assumption in the function is that callers hold the AioContext lock of the BlockBackend (this is required by the drain calls in it). In order to avoid deadlock in the nested event loop, bdrv_graph_wrlock() has then to be called with the root BlockDriverState as its parameter instead of NULL, so that this AioContext lock is temporarily dropped. Fixes: https://issues.redhat.com/browse/RHEL-1761 Signed-off-by: Kevin Wolf <[email protected]> Message-ID: <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>
bdrv_graph_wrunlock() calls aio_poll(), which may run callbacks that have a nested event loop. Nested event loops can depend on other iothreads making progress, so in order to allow them to make progress it must not hold the AioContext lock of another thread while calling aio_poll(). This introduces a @bs parameter to bdrv_graph_wrunlock() whose AioContext is temporarily dropped (which matches bdrv_graph_wrlock()), and a bdrv_graph_wrunlock_ctx() that can be used if the BlockDriverState doesn't necessarily exist any more when unlocking. This also requires a change to bdrv_schedule_unref(), which was relying on the incorrectly taken lock. It needs to take the lock itself now. While this is a separate bug, it can't be fixed a separate patch because otherwise the intermediate state would either deadlock or try to release a lock that we don't even hold. Signed-off-by: Kevin Wolf <[email protected]> Message-ID: <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> [kwolf: Fixed up bdrv_schedule_unref()] Signed-off-by: Kevin Wolf <[email protected]>
…ock_status Using fleecing backup like in [0] on a qcow2 image (with metadata preallocation) can lead to the following assertion failure: > bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed. In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag will be set by the qcow2 driver, so the caller will recursively check the file child. Then the BDRV_BLOCK_ZERO set too. Later up the call chain, in bdrv_co_do_block_status() for the snapshot-access driver, the assertion failure will happen, because both flags are set. To fix it, clear the recurse flag after the recursive check was done. In detail: > #0 qcow2_co_block_status Returns 0x45 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID. > eurecom-s3#1 bdrv_co_do_block_status Because of the data flag, bdrv_co_do_block_status() will now also set BDRV_BLOCK_ALLOCATED. Because of the recurse flag, bdrv_co_do_block_status() for the bdrv_file child will be called, which returns 0x16 = BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ZERO. Now the return value inherits the zero flag. Returns 0x57 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_ZERO. > eurecom-s3#2 bdrv_co_common_block_status_above > eurecom-s3#3 bdrv_co_block_status_above > eurecom-s3#4 bdrv_co_block_status > eurecom-s3#5 cbw_co_snapshot_block_status > eurecom-s3#6 bdrv_co_snapshot_block_status > eurecom-s3#7 snapshot_access_co_block_status > eurecom-s3#8 bdrv_co_do_block_status Return value is propagated all the way up to here, where the assertion failure happens, because BDRV_BLOCK_RECURSE and BDRV_BLOCK_ZERO are both set. > eurecom-s3#9 bdrv_co_common_block_status_above > eurecom-s3#10 bdrv_co_block_status_above > eurecom-s3#11 block_copy_block_status > eurecom-s3#12 block_copy_dirty_clusters > eurecom-s3#13 block_copy_common > eurecom-s3#14 block_copy_async_co_entry > eurecom-s3#15 coroutine_trampoline [0]: > #!/bin/bash > rm /tmp/disk.qcow2 > ./qemu-img create /tmp/disk.qcow2 -o preallocation=metadata -f qcow2 1G > ./qemu-img create /tmp/fleecing.qcow2 -f qcow2 1G > ./qemu-img create /tmp/backup.qcow2 -f qcow2 1G > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 \ > --blockdev qcow2,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.qcow2 \ > --blockdev qcow2,node-name=node2,file.driver=file,file.filename=/tmp/backup.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write", "file": "node0", "target": "node1", "node-name": "node3" } } > {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", "file": "node3", "node-name": "snap0" } } > {"execute": "blockdev-backup", "arguments": { "device": "snap0", "target": "node1", "sync": "full", "job-id": "backup0" } } > EOF Signed-off-by: Fiona Ebner <[email protected]> Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]> (cherry picked from commit 8a9be79) Signed-off-by: Michael Tokarev <[email protected]>
Commit f4e1168 (linux-user: Split out host_sig{segv,bus}_handler) introduced a bug, when returning from host_sigbus_handler the PC is never set. Thus cpu_loop_exit_restore is called with a zero PC and we immediate get a SIGSEGV. Signed-off-by: Robbin Ehn <[email protected]> Fixes: f4e1168 ("linux-user: Split out host_sig{segv,bus}_handler") Reviewed-by: Palmer Dabbelt <[email protected]> Message-Id: <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 6d91315) Signed-off-by: Michael Tokarev <[email protected]>
A typo in sizeof_reg put the registers at the wrong offset. Simplify the expressions to use positive addresses from the start of uc_mcontext instead of negative addresses from the end of uc_mcontext. Reported-by: Vineet Gupta <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Alistair Francis <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 1b21fe2) Signed-off-by: Michael Tokarev <[email protected]>
When tcg_out_qemu_st_{index,direct} were merged, the direct case for
MO_64 was omitted, causing qemu_st_i64 to be encoded as 0xffffffff due
to underflow when adding h.base and h.index.
Fixes: 1df6d61 ("tcg/arm: Introduce HostAddress")
Signed-off-by: Joseph Burt <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 9f6523e)
Signed-off-by: Michael Tokarev <[email protected]>
When HASH_REPORT is negotiated, the guest_hdr_len might be larger than the size of the mergeable rx buffer header. Using virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack overflow in this case. Fixing this by using virtio_net_hdr_v1_hash instead. Reported-by: Xiao Lei <[email protected]> Cc: Yuri Benditovich <[email protected]> Cc: [email protected] Cc: Mauro Matteo Cascella <[email protected]> Fixes: CVE-2023-6693 Fixes: e22f060 ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev <[email protected]> Signed-off-by: Jason Wang <[email protected]> (cherry picked from commit 2220e81) Signed-off-by: Michael Tokarev <[email protected]>
There is a bug in the blklogwrites driver pertaining to logging "write
zeroes" operations, causing log corruption. This can be easily observed
by setting detect-zeroes to something other than "off" for the driver.
The issue is caused by a concurrency bug pertaining to the fact that
"write zeroes" operations have to be logged in two parts: first the log
entry metadata, then the zeroed-out region. While the log entry
metadata is being written by bdrv_co_pwritev(), another operation may
begin in the meanwhile and modify the state of the blklogwrites driver.
This is as intended by the coroutine-driven I/O model in QEMU, of
course.
Unfortunately, this specific scenario is mishandled. A short example:
1. Initially, in the current operation (eurecom-s3#1), the current log sector
number in the driver state is only incremented by the number of sectors
taken by the log entry metadata, after which the log entry metadata is
written. The current operation yields.
2. Another operation (eurecom-s3#2) may start while the log entry metadata is
being written. It uses the current log position as the start offset for
its log entry. This is in the sector right after the operation eurecom-s3#1 log
entry metadata, which is bad!
3. After bdrv_co_pwritev() returns (eurecom-s3#1), the current log sector
number is reread from the driver state in order to find out the start
offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the
offset will be the sector right after the (misplaced) operation eurecom-s3#2 log
entry, which means that the zeroed-out region begins at the wrong
offset.
4. As a result of the above, the log is corrupt.
Fix this by only reading the driver metadata once, computing the
offsets and sizes in one go (including the optional zeroed-out region)
and setting the log sector number to the appropriate value for the next
operation in line.
Signed-off-by: Ari Sundholm <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit a9c8ea9)
Signed-off-by: Michael Tokarev <[email protected]>
Add a filter function for QMP responses that contain QEMU's automatically generated node ids. The ids change between runs and must be masked in the reference output. The next commit will use this new function. Signed-off-by: Stefan Hajnoczi <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> (cherry picked from commit da62b50) Signed-off-by: Michael Tokarev <[email protected]>
The common.qemu bash functions allow tests to interact with the QMP monitor of a QEMU process. I spent two days trying to update 141 when the order of the test output changed, but found it would still fail occassionally because printf() and QMP events race with synchronous QMP communication. I gave up and ported 141 to the existing Python API for QMP tests. The Python API is less affected by the order in which QEMU prints output because it does not print all QMP traffic by default. The next commit changes the order in which QMP messages are received. Make 141 reliable first. Cc: Hanna Czenczek <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> (cherry picked from commit 9ee2dd4) Signed-off-by: Michael Tokarev <[email protected]>
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not polled during nested event loops. The coroutine currently reschedules itself in the main loop's qemu_aio_context AioContext, which is polled during nested event loops. One known problem is that QMP device-add calls drain_call_rcu(), which temporarily drops the BQL, leading to all sorts of havoc like other vCPU threads re-entering device emulation code while another vCPU thread is waiting in device emulation code with aio_poll(). Paolo Bonzini suggested running non-coroutine QMP handlers in the iohandler AioContext. This avoids trouble with nested event loops. His original idea was to move coroutine rescheduling to monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch() because we don't know if the QMP handler needs to run in coroutine context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have been nicer since it's associated with the monitor implementation and not as general as qmp_dispatch(), which is also used by qemu-ga. A number of qemu-iotests need updated .out files because the order of QMP events vs QMP responses has changed. Solves Issue #1933. Cc: [email protected] Fixes: 7bed899 ("device_core: use drain_call_rcu in in qmp_device_add") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985 Buglink: https://issues.redhat.com/browse/RHEL-17369 Signed-off-by: Stefan Hajnoczi <[email protected]> Message-ID: <[email protected]> Reviewed-by: Kevin Wolf <[email protected]> Tested-by: Fiona Ebner <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> (cherry picked from commit effd60c) Signed-off-by: Michael Tokarev <[email protected]>
On a loaded system with --enable-debug, this test can take longer than 5 minutes. Raising the timeout to 6 minutes gives greater headroom for such situations. Signed-off-by: Daniel P. Berrangé <[email protected]> [thuth: Increase the timeout to 6 minutes for very loaded systems] Signed-off-by: Thomas Huth <[email protected]> Message-Id: <[email protected]> Signed-off-by: Alex Bennée <[email protected]> (cherry picked from commit e8a12fe) Signed-off-by: Michael Tokarev <[email protected]> (Mjt: context fixup in tests/qtest/meson.build)
r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register by the guest. The host uses 3 bits of the index for ITLB indexing and 4 bits for DTLB, but there's only 7 entries in the ITLB array and 10 in the DTLB array, so a malicious guest may trigger out-of-bound access to these arrays. Change split_tlb_entry_spec return type to bool to indicate whether TLB way passed to it is valid. Change get_tlb_entry to return NULL in case invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that requested TLB way and entry indices are valid. Add checks to the [rwi]tlb helpers that requested TLB way is valid and return 0 or do nothing when it's not. Cc: [email protected] Fixes: b67ea0c ("target-xtensa: implement memory protection options") Signed-off-by: Max Filippov <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]> (cherry picked from commit 604927e) Signed-off-by: Michael Tokarev <[email protected]>
In commit 1b7bc9b we changed handle_vec_simd_sqshrn() so that instead of starting with a 0 value and depositing in each new element from the narrowing operation, it instead started with the raw result of the narrowing operation of the first element. This is fine in the vector case, because the deposit operations for the second and subsequent elements will always overwrite any higher bits that might have been in the first element's result value in tcg_rd. However in the scalar case we only go through this loop once. The effect is that for a signed narrowing operation, if the result is negative then we will now return a value where the bits above the first element are incorrectly 1 (because the narrowfn returns a sign-extended result, not one that is truncated to the element size). Fix this by using an extract operation to get exactly the correct bits of the output of the narrowfn for element 1, instead of a plain move. Cc: [email protected] Fixes: 1b7bc9b ("target/arm: Avoid tcg_const_ptr in handle_vec_simd_sqshrn") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089 Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Message-id: [email protected] (cherry picked from commit 6fffc83) Signed-off-by: Michael Tokarev <[email protected]>
A typo in the implementation of isar_feature_aa64_tidcp1() means we were checking the field in the wrong ID register, so we might have provided the feature on CPUs that don't have it and not provided it on CPUs that should have it. Correct this bug. Cc: [email protected] Fixes: 9cd0c0d "target/arm: Implement FEAT_TIDCP1" Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2120 Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Message-id: [email protected] (cherry picked from commit ee0a2e3) Signed-off-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
* Basic support for riscv * Add build of SymQEMU for Risc-V in Dockerfile --------- Co-authored-by: Vlada Logunova <[email protected]>
Added helper for 10 and 11 arguments. Updated test cases.
|
I cleaned the history (renamed commits, squashed them to a few commits that are consistent). This will be a merge commit (not a squash & merge, which would loose the commit history from QEMU and make merging / maintenance more difficult) so we want to have meaningful commits. |
|
it's ok, let's merge |
|
Great thanks for the work ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It has not been tested yet; not to merge for now.