Branch: refs/heads/staging-9.2
Home: https://github.com/qemu/qemu
Commit: b8df4dbf13ba58179aa78ce58633205ddef03747
https://github.com/qemu/qemu/commit/b8df4dbf13ba58179aa78ce58633205ddef03747
Author: Alex Bennée <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M include/hw/arm/bsa.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/gtimer.h
M target/arm/helper.c
Log Message:
-----------
target/arm: Implement SEL2 physical and virtual timers
When FEAT_SEL2 was implemented the SEL2 timers were missed. This
shows up when building the latest Hafnium with SPMC_AT_EL=2. The
actual implementation utilises the same logic as the rest of the
timers so all we need to do is:
- define the timers and their access functions
- conditionally add the correct system registers
- create a new accessfn as the rules are subtly different to the
existing secure timer
Fixes: e9152ee91c (target/arm: add ARMv8.4-SEL2 system registers)
Signed-off-by: Alex Bennée <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Cc: Andrei Homescu <[email protected]>
Cc: Arve Hjønnevåg <[email protected]>
Cc: Rémi Denis-Courmont <[email protected]>
[PMM: CP_ACCESS_TRAP_UNCATEGORIZED -> CP_ACCESS_UNDEFINED;
offset logic now in gt_{indirect,direct}_access_timer_offset() ]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit f9f99d7ca522339c1de2292f132bb8ddc3471c39)
(Mjt: CP_ACCESS_UNDEFINED -> CP_ACCESS_TRAP_UNCATEGORIZED)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e3effbc85b9dd4821e8a7c0d6ae4792ef3aad614
https://github.com/qemu/qemu/commit/e3effbc85b9dd4821e8a7c0d6ae4792ef3aad614
Author: Alex Bennée <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for virt machine
Signed-off-by: Alex Bennée <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 5dcaea8bcd82972add29eef350547f922fb4caa2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3c079a2464e443f416ee1dc27b60d5bb7ecd29de
https://github.com/qemu/qemu/commit/3c079a2464e443f416ee1dc27b60d5bb7ecd29de
Author: Alex Bennée <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/arm/sbsa-ref.c
Log Message:
-----------
hw/arm: enable secure EL2 timers for sbsa machine
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 9a9d9e82093efa22e3e2bdaac0f24c823f8786f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5765732dd041b1bcfbc61e516df5f47210f7682f
https://github.com/qemu/qemu/commit/5765732dd041b1bcfbc61e516df5f47210f7682f
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Correct LDRD atomicity and fault behaviour
Our LDRD implementation is wrong in two respects:
* if the address is 4-aligned and the load crosses a page boundary
and the second load faults and the first load was to the
base register (as in cases like "ldrd r2, r3, [r2]", then we
must not update the base register before taking the fault
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of the loads in LDRD to use a single
tcg_gen_qemu_ld_i64() and split the result into the destination
registers. This allows us to get the atomicity requirements
right, and also implicitly means that we won't update the
base register too early for the page-crossing case.
Note that because we no longer increment 'addr' by 4 in the course of
performing the LDRD we must change the adjustment value we pass to
op_addr_ri_post() and op_addr_rr_post(): it no longer needs to
subtract 4 to get the correct value to use if doing base register
writeback.
STRD has the same problem with not getting the atomicity right;
we will deal with that in the following commit.
Cc: [email protected]
Reported-by: Stu Grossman <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit cde3247651dc998da5dc1005148302a90d72f21f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fb2a2c8acab34231e9475c3e4277efc299ff910c
https://github.com/qemu/qemu/commit/fb2a2c8acab34231e9475c3e4277efc299ff910c
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Correct STRD atomicity
Our STRD implementation doesn't correctly implement the requirement:
* if the address is 8-aligned the access must be a 64-bit
single-copy atomic access, not two 32-bit accesses
Rewrite the handling of STRD to use a single tcg_gen_qemu_st_i64()
of a value produced by concatenating the two 32 bit source registers.
This allows us to get the atomicity right.
As with the LDRD change, now that we don't update 'addr' in the
course of performing the store we need to adjust the offset
we pass to op_addr_ri_post() and op_addr_rr_post().
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit ee786ca115045a2b7e86ac3073b0761cb99e0d49)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a806c1f16cfc8fe20f6c4b87ec9cfe224d7a7bf7
https://github.com/qemu/qemu/commit/a806c1f16cfc8fe20f6c4b87ec9cfe224d7a7bf7
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M util/qemu-timer.c
Log Message:
-----------
util/qemu-timer.c: Don't warp timer from timerlist_rearm()
Currently we call icount_start_warp_timer() from timerlist_rearm().
This produces incorrect behaviour, because timerlist_rearm() is
called, for instance, when a timer callback modifies its timer. We
cannot decide here to warp the timer forwards to the next timer
deadline merely because all_cpu_threads_idle() is true, because the
timer callback we were called from (or some other callback later in
the list of callbacks being invoked) may be about to raise a CPU
interrupt and move a CPU from idle to ready.
The only valid place to choose to warp the timer forward is from the
main loop, when we know we have no outstanding IO or timer callbacks
that might be about to wake up a CPU.
For Arm guests, this bug was mostly latent until the refactoring
commit f6fc36deef6abc ("target/arm/helper: Implement
CNTHCTL_EL2.CNT[VP]MASK"), which exposed it because it refactored a
timer callback so that it happened to call timer_mod() first and
raise the interrupt second, when it had previously raised the
interrupt first and called timer_mod() afterwards.
This call seems to have originally derived from the
pre-record-and-replay icount code, which (as of e.g. commit
db1a49726c3c in 2010) in this location did a call to
qemu_notify_event(), necessary to get the icount code in the vCPU
round-robin thread to stop and recalculate the icount deadline when a
timer was reprogrammed from the IO thread. In current QEMU,
everything is done on the vCPU thread when we are in icount mode, so
there's no need to try to notify another thread here.
I suspect that the other reason why this call was doing icount timer
warping is that it pre-dates commit efab87cf79077a from 2015, which
added a call to icount_start_warp_timer() to main_loop_wait(). Once
the call in timerlist_rearm() has been removed, if the timer
callbacks don't cause any CPU to be woken up then we will end up
calling icount_start_warp_timer() from main_loop_wait() when the rr
main loop code calls rr_wait_io_event().
Remove the incorrect call from timerlist_rearm().
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2703
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 02ae315467cee589d02dfb89e13a2a6a8de09fc5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fc9b77c214d68873bdf99be7313e8522b5414692
https://github.com/qemu/qemu/commit/fc9b77c214d68873bdf99be7313e8522b5414692
Author: Eugenio Pérez <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M net/net.c
Log Message:
-----------
net: parameterize the removing client from nc list
This change is used in later commits so we can avoid the removal of the
netclient if it is delayed.
No functional change intended.
Reviewed-by: Si-Wei Liu <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: Eugenio Pérez <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit db0d4017f9b9e87f962b35dd19a4912bbfcd3cbc)
(Mjt: pick this one up for the following change,
"net: move backend cleanup to NIC cleanup")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e4f41e3c54c5c23fa07a26814a74d419edae751f
https://github.com/qemu/qemu/commit/e4f41e3c54c5c23fa07a26814a74d419edae751f
Author: Eugenio Pérez <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M net/net.c
M net/vhost-vdpa.c
Log Message:
-----------
net: move backend cleanup to NIC cleanup
Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net
structures if peer nic is present") effectively delayed the backend
cleanup, allowing the frontend or the guest to access it resources as
long as the frontend is still visible to the guest.
However it does not clean up the resources until the qemu process is
over. This causes an effective leak if the device is deleted with
device_del, as there is no way to close the vdpa device. This makes
impossible to re-add that device to this or other QEMU instances until
the first instance of QEMU is finished.
Move the cleanup from qemu_cleanup to the NIC deletion and to
net_cleanup.
Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net structures if
peer nic is present")
Reported-by: Lei Yang <[email protected]>
Signed-off-by: Eugenio Pérez <[email protected]>
Signed-off-by: Jonah Palmer <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit e7891c575fb294618b172119a91c892b8f4384a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4bb7ea7f644b24783730d5d060b648a2e00382af
https://github.com/qemu/qemu/commit/4bb7ea7f644b24783730d5d060b648a2e00382af
Author: Stefano Stabellini <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/xen/xen-mapcache.c
Log Message:
-----------
xen: No need to flush the mapcache for grants
On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
mappings. Since recently we started reusing the mapcache also to keep
track of grants mappings. However, there is no need to remove grant
mappings on IOREQ_TYPE_INVALIDATE requests, we shouldn't do that. So
remove the function call.
Fixes: 9ecdd4bf08 (xen: mapcache: Add support for grant mappings)
Cc: [email protected]
Reported-by: Olaf Hering <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Signed-off-by: Stefano Stabellini <[email protected]>
Signed-off-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Anthony PERARD <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Anthony PERARD <[email protected]>
(cherry picked from commit 68adcc784bad13421ac7211c316a751fb99fcb94)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5c4f76f393884f8eb6be122733d07e7bb7683a92
https://github.com/qemu/qemu/commit/5c4f76f393884f8eb6be122733d07e7bb7683a92
Author: Nicholas Piggin <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/ppc/pnv_occ.c
Log Message:
-----------
ppc/pnv/occ: Fix common area sensor offsets
The commit to fix the OCC common area sensor mappings didn't update the
register offsets to match.
Before this change, skiboot reports:
[ 0.347100086,3] OCC: Chip 0 sensor data invalid
Afterward, there is no error and the sensor_groups directory appears
under /sys/firmware/opal/.
The SLW_IMAGE_BASE address looks like a workaround to intercept firmware
memory accesses, but that does not seem to be required now (and would
have been broken by the OCC common area region mapping change anyway).
So it can be removed.
Fixes: 3a1b70b66b5cb4 ("ppc/pnv: Fix OCC common area region mapping")
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 40a6dabffb152a19205222bebba23ddaf60e7201
https://github.com/qemu/qemu/commit/40a6dabffb152a19205222bebba23ddaf60e7201
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet numbers
The smc91c111 uses packet numbers as an index into its internal
s->data[][] array. Valid packet numbers are between 0 and 3, but
the code does not generally check this, and there are various
places where the guest can hand us an arbitrary packet number
and cause an out-of-bounds access to the data array.
Add validation of packet numbers. The datasheet is not very
helpful about how guest errors like this should be handled:
it says nothing on the subject, and none of the documented
error conditions are relevant. We choose to log the situation
with LOG_GUEST_ERROR and silently ignore the attempted operation.
In the places where we are about to access the data[][] array
using a packet number and we know the number is valid because
we got it from somewhere that has already validated, we add
an assert() to document that belief.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 2fa3a5b9469615d06091cf473d172794148e1248)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e678cc50efb74cde158fb39afde58032ce01c784
https://github.com/qemu/qemu/commit/e678cc50efb74cde158fb39afde58032ce01c784
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte
which is at the end of the data area and CRC. However, we don't
sanitize the length field in the packet buffer, so if the guest sets
the length field to something large we will try to read past the end
of the packet data buffer when we access the control byte.
As usual, the datasheet says nothing about the behaviour of the
hardware if the guest misprograms it in this way. It says only that
the maximum valid length is 2048 bytes. We choose to log the guest
error and silently drop the packet.
This requires us to factor out the "mark the tx packet as complete"
logic, so we can call it for this "drop packet" case as well as at
the end of the loop when we send a valid packet.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 911f6a46b391c7b9d6e548ffd359cbfe9753942e
https://github.com/qemu/qemu/commit/911f6a46b391c7b9d6e548ffd359cbfe9753942e
Author: Peter Maydell <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Don't allow data register access to overrun buffer
For accesses to the 91c111 data register, the address within the
packet's data frame is determined by a combination of the pointer
register and the offset used to access the data register, so that you
can access data at effectively wider than byte width. The pointer
register's pointer field is 11 bits wide, which is exactly the size
to index a 2048-byte data frame.
We weren't quite getting the logic right for ensuring that we end up
with a pointer value to use in the s->data[][] array that isn't out
of bounds:
* we correctly mask when getting the initial pointer value
* for the "autoincrement the pointer register" case, we
correctly mask after adding 1 so that the pointer register
wraps back around at the 2048 byte mark
* but for the non-autoincrement case where we have to add the
low 2 bits of the data register offset, we don't account
for the possibility that the pointer register is 0x7ff
and the addition should wrap
Fix this bug by factoring out the "get the p value to use as an array
index" into a function, making it use FIELD macro names rather than
hard-coded constants, and having a utility function that does "add a
value and wrap it" that we can use both for the "autoincrement" and
"add the offset bits" codepaths.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5ae37bf092af0ae9fb0a59104c5c8fa1cee1ea6f
https://github.com/qemu/qemu/commit/5ae37bf092af0ae9fb0a59104c5c8fa1cee1ea6f
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M include/hw/xen/arch_hvm.h
Log Message:
-----------
hw/xen/hvm: Fix Aarch64 typo
There is no TARGET_ARM_64 definition. Luckily enough,
when TARGET_AARCH64 is defined, TARGET_ARM also is.
Fixes: 733766cd373 ("hw/arm: introduce xenpvh machine")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 3a11b653a63fee0e43f4ab84b93f068b961d8fe7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0dd985fc1dd9aa36c5ae3afa478a92c15913fb35
https://github.com/qemu/qemu/commit/0dd985fc1dd9aa36c5ae3afa478a92c15913fb35
Author: Kevin Wolf <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M block/snapshot.c
Log Message:
-----------
block: Zero block driver state before reopening
Block drivers assume in their .bdrv_open() implementation that their
state in bs->opaque has been zeroed; it is initially allocated with
g_malloc0() in bdrv_open_driver().
bdrv_snapshot_goto() needs to make sure that it is zeroed again before
calling drv->bdrv_open() to avoid that block drivers use stale values.
One symptom of this bug is VMDK running into a double free when the user
tries to apply an internal snapshot like 'qemu-img snapshot -a test
test.vmdk'. This should be a graceful error because VMDK doesn't support
internal snapshots.
==25507== Invalid free() / delete / delete[] / realloc()
==25507== at 0x484B347: realloc (vg_replace_malloc.c:1801)
==25507== by 0x54B592A: g_realloc (gmem.c:171)
==25507== by 0x1B221D: vmdk_add_extent (../block/vmdk.c:570)
==25507== by 0x1B1084: vmdk_open_sparse (../block/vmdk.c:1059)
==25507== by 0x1AF3D8: vmdk_open (../block/vmdk.c:1371)
==25507== by 0x1A2AE0: bdrv_snapshot_goto (../block/snapshot.c:299)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
==25507== Address 0x832f3e0 is 0 bytes inside a block of size 272 free'd
==25507== at 0x4846B83: free (vg_replace_malloc.c:989)
==25507== by 0x54AEAC4: g_free (gmem.c:208)
==25507== by 0x1AF629: vmdk_close (../block/vmdk.c:2889)
==25507== by 0x1A2A9C: bdrv_snapshot_goto (../block/snapshot.c:290)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
This error was discovered by fuzzing qemu-img.
Cc: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851
Reported-by: Denis Rastyogin <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e7453f0cd3b962e038fc5228d592cb5bccf443b9
https://github.com/qemu/qemu/commit/e7453f0cd3b962e038fc5228d592cb5bccf443b9
Author: Greg Kurz <[email protected]>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M docs/devel/build-system.rst
M docs/devel/kconfig.rst
Log Message:
-----------
docs: Rename default-configs to configs
This was missed at the time.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise")
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/182a5b510fc7...e7453f0cd3b9
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
