Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: 299644d028a98d9265f1a03a9046a47f4c601c02
https://github.com/qemu/qemu/commit/299644d028a98d9265f1a03a9046a47f4c601c02
Author: Jack Wang <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M hw/virtio/virtio-qmp.c
Log Message:
-----------
qmp: Fix a typo for a USO feature
There is a copy & paste error, USO6 should be there.
Fixes: 58f81689789f ("qmp: update virtio feature maps, vhost-user-gpio
introspection")
Signed-off-by: Jack Wang <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 5fbcbf76a19a0d3500a4103fc8876c6cace2afcf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: db3d5ee5ccefa12e9ddaa6cca13ede15ea16be13
https://github.com/qemu/qemu/commit/db3d5ee5ccefa12e9ddaa6cca13ede15ea16be13
Author: Li Zhijian <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Fix transition to COLO state from precopy
Commit 4881411136 ("migration: Always set DEVICE state") set a new DEVICE
state before completed during migration, which broke the original transition
to COLO. The migration flow for precopy has changed to:
active -> pre-switchover -> device -> completed.
This patch updates the transition state to ensure that the Pre-COLO
state corresponds to DEVICE state correctly.
Cc: qemu-stable <[email protected]>
Fixes: 4881411136 ("migration: Always set DEVICE state")
Signed-off-by: Li Zhijian <[email protected]>
Reviewed-by: Zhang Chen <[email protected]>
Tested-by: Zhang Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 0b5bf4ea76205a93386c5e02fbb519871a62e677)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fb7d253875f937ac9d98777d416931dc06deabde
https://github.com/qemu/qemu/commit/fb7d253875f937ac9d98777d416931dc06deabde
Author: Nabih Estefan <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M hw/arm/aspeed_ast27x0.c
Log Message:
-----------
hw/arm/ast27x0: Fix typo in LTPI address
The address for LTPI has one more 0 that it should, bug introduced in
commit 91064bea6b2d747a981cb3bd2904e56f443e6c67.
Signed-off-by: Nabih Estefan <[email protected]>
Fixes: 91064bea6b2d ("aspeed: ast27x0: Map unimplemented devices in SoC memory")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit cacd8fb08d3f992ef9cdf4c26a2d28ced409cfd4)
(Mjt: context fixup)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2e384f3a40d0c04c2e2258a9d4f3551639970d52
https://github.com/qemu/qemu/commit/2e384f3a40d0c04c2e2258a9d4f3551639970d52
Author: Jamin Lin <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M hw/arm/aspeed_ast10x0.c
M hw/arm/aspeed_ast2600.c
M hw/arm/aspeed_ast27x0.c
Log Message:
-----------
hw/arm/aspeed: Fix missing SPI IRQ connection causing DMA interrupt failure
It did not connect SPI IRQ to the Interrupt Controller, so even the SPI
model raised the IRQ, the interrupt was not received. The CPU therefore
did not trigger an interrupt via the controller, and the firmware never
received the interrupt.
Fixes: 356b230ed13889e09d087a96498887de695df17e ("aspeed/soc: Add AST1030
support")
Fixes: f25c0ae1079dc0b9de02676eb3e3949a09df9f41 ("aspeed/soc: Add AST2600
support")
Fixes: 5dd883ab0635c9f715c77cc32622e458a0724581 ("aspeed/soc: Add AST2700
support")
Signed-off-by: Jamin Lin <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 510d5c61ad3eb1690b61c804d38c984527a5ea62)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 74ef23cd703e64f241919da42c652ef5e88fb4b2
https://github.com/qemu/qemu/commit/74ef23cd703e64f241919da42c652ef5e88fb4b2
Author: Peter Maydell <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M hw/arm/armv7m.c
Log Message:
-----------
hw/arm/armv7m: Disable reentrancy guard for v7m_sysreg_ns_ops MRs
For M-profile cores which support TrustZone, there are some memory
areas which are "NS aliases" -- a Secure access to these addresses
really performs an NS access to a different part of the device. We
implement these using MemoryRegionOps read and write functions which
pass the access on with adjusted attributes using
memory_region_dispatch_read() and memory_region_dispatch_write().
Since the MR we are dispatching to is owned by the same device that
owns the NS-alias MR (the TYPE_ARMV7M container object), this trips
the reentrancy-guard that is applied by access_with_adjusted_size().
Mark the NS alias MemoryRegions as disable_reentrancy_guard; this is
safe because v7m_sysreg_ns_read() and v7m_sysreg_ns_write() do not
touch any of the device's state. (Any further reentrancy attempts by
the underlying MR will still be caught.)
Without this fix, an attempt to read from an address like 0xe002e010,
which is a register in the NS systick alias, will fail and provoke
qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: v7m_systick
at addr: 0x0
We didn't notice this earlier because almost all code accesses
the registers and systick via the non-alias addresses; the NS
aliases are only need for the rarer case of Secure code that needs
to manage the NS timer or system state on behalf of NS code.
Note that although the v7m_systick_ops read and write functions
also call memory_region_dispatch_{read,write}, this MR does not
need to have the reentrancy-guard disabled because the underlying
MR that it forwards to is owned by a different device (the
TYPE_SYSTICK timer device).
Reported via a stackoverflow question:
https://stackoverflow.com/questions/79808107/what-this-error-is-even-about-qemu-system-arm-warning-blocked-re-entrant-io
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4a934d284dfac9fa19b0f47874f12d9b3519c21c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2bbb702dc687ec3a1e8d01fed34bb031206ca290
https://github.com/qemu/qemu/commit/2bbb702dc687ec3a1e8d01fed34bb031206ca290
Author: Peter Maydell <[email protected]>
Date: 2025-11-24 (Mon, 24 Nov 2025)
Changed paths:
M hw/display/exynos4210_fimd.c
Log Message:
-----------
hw/display/exynos4210_fimd: Account for zero length in
fimd_update_memory_section()
In fimd_update_memory_section() we attempt ot find and map part of
the RAM MR which backs the framebuffer, based on guest-configurable
size and start address.
If the guest configures framebuffer settings which result in a
zero-sized framebuffer, we hit an assertion(), because
memory_region_find() will return a NULL mem_section.mr.
Explicitly check for the zero-size case and treat this as a
guest error.
Because we now have a code path which can reach error_return without
calling memory_region_find to set w->mem_section, we must NULL out
w->mem_section.mr after the unref of the old MR, so that error_return
does not incorrectly double-unref the old MR.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1407
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 579be921f509fb9d2deccc4233496e36b221abb3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1545d807bbdb4d2781feacffcfcfa006f611140c
https://github.com/qemu/qemu/commit/1545d807bbdb4d2781feacffcfcfa006f611140c
Author: Marc-André Lureau <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M ui/vdagent.c
Log Message:
-----------
ui/vdagent: fix windows agent regression
Since commit f626116f ("ui/vdagent: factor out clipboard peer
registration"), the QEMU clipboard serial is reset whenever the vdagent
chardev receives the guest caps. This triggers a CHR_EVENT_CLOSED which
is handled by virtio_serial_close() to notify the guest.
The "reconnection logic" is there to reset the agent when a
client (dbus, spice etc) reconnects, or the agent is restarted.
It is required to sync the clipboard serials and to prevent races or
loops due to clipboard managers on both ends (but this is not
implemented by windows vdagent).
The Unix agent has been reconnecting without resending caps, thus
working with this approach.
However, the Windows agent does not seem to have a way to handle
VIRTIO_CONSOLE_PORT_OPEN=0 event and do not receive further data...
Let's not trigger this disconnection/reset logic if the agent does not
support VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL.
Fixes: f626116f ("ui/vdagent: factor out clipboard peer registration")
Signed-off-by: Marc-André Lureau <[email protected]>
Reported-by: Lucas Kornicki <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Tested-by: Lucas Kornicki <[email protected]>
(cherry picked from commit 4be62d311791bf9d318f5139439d170ad5112279)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7191572f62c65ea905fedad815abfa901e1f5536
https://github.com/qemu/qemu/commit/7191572f62c65ea905fedad815abfa901e1f5536
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M chardev/char-pty.c
Log Message:
-----------
chardev/char-pty: Do not ignore chr_write() failures
Cc: [email protected]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 303f6049358e2ef35f2b107d6bd1a5be07ec35e9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 13aae93f72f304235d46950b05e71b3267456771
https://github.com/qemu/qemu/commit/13aae93f72f304235d46950b05e71b3267456771
Author: [email protected] <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui/vnc: Fix qemu abort when query vnc info
When there is no display device on qemu machine,
and user only access qemu by remote vnc.
At the same time user input `info vnc` by QMP,
the qemu will abort.
To avoid the abort above, I add display device check,
when query vnc info in qmp_query_vnc_servers().
Reviewed-by: Marc-AndréLureau <[email protected]>
Signed-off-by: Alano Song <[email protected]>
[ Marc-André - removed useless Error *err ]
Signed-off-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 4c1646e23f761e3dc6d88c8995f13be8f668a012)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: db6d3678990fd1f388f65cd53aac412995ed7fc5
https://github.com/qemu/qemu/commit/db6d3678990fd1f388f65cd53aac412995ed7fc5
Author: Kevin Wolf <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M block/block-backend.c
Log Message:
-----------
block-backend: Fix race when resuming queued requests
When new requests arrive at a BlockBackend that is currently drained,
these requests are queued until the drain section ends.
There is a race window between blk_root_drained_end() waking up a queued
request in an iothread from the main thread and blk_wait_while_drained()
actually being woken up in the iothread and calling blk_inc_in_flight().
If the BlockBackend is drained again during this window, drain won't
wait for this request and it will sneak in when the BlockBackend is
already supposed to be quiesced. This causes assertion failures in
bdrv_drain_all_begin() and can have other unintended consequences.
Fix this by increasing the in_flight counter immediately when scheduling
the request to be resumed so that the next drain will wait for it to
complete.
Cc: [email protected]
Reported-by: Andrey Drobyshev <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Tested-by: Andrey Drobyshev <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 8eeaa706ba73251063cb80d87ae838d2d5b08e9a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 092b82b6aaa352e76522692d7797a1ab06b1cfaf
https://github.com/qemu/qemu/commit/092b82b6aaa352e76522692d7797a1ab06b1cfaf
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M block/file-posix.c
Log Message:
-----------
file-posix: populate pwrite_zeroes_alignment
Linux block devices require write zeroes alignment whereas files do not.
It may come as a surprise that block devices opened in buffered I/O mode
require the alignment for write zeroes requests although normal
read/write requests do not.
Therefore it is necessary to populate the pwrite_zeroes_alignment field.
Cc: [email protected]
Signed-off-by: Stefan Hajnoczi <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 98e788b91ad037193b1fb375561ef7e0fef3c2fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: df502b9f180287e00f6b1296266c5bead5201f4d
https://github.com/qemu/qemu/commit/df502b9f180287e00f6b1296266c5bead5201f4d
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M block.c
M block/block-backend.c
M include/system/block-backend-io.h
Log Message:
-----------
block: use pwrite_zeroes_alignment when writing first sector
Since commit 5634622bcb33 ("file-posix: allow BLKZEROOUT with -t
writeback"), qemu-img create errors out on a Linux loop block device
with a 4 KB sector size:
# dd if=/dev/zero of=blockfile bs=1M count=1024
# losetup --sector-size 4096 /dev/loop0 blockfile
# qemu-img create -f raw /dev/loop0 1G
Formatting '/dev/loop0', fmt=raw size=1073741824
qemu-img: /dev/loop0: Failed to clear the new image's first sector: Invalid
argument
Use the pwrite_zeroes_alignment block limit to avoid misaligned
fallocate(2) or ioctl(BLKZEROOUT) in the block/file-posix.c block
driver.
Cc: [email protected]
Fixes: 5634622bcb33 ("file-posix: allow BLKZEROOUT with -t writeback")
Reported-by: Jean-Louis Dupond <[email protected]>
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/3127
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
Message-ID: <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit d704a13d2c025779bc91d04e127427347ddcf3b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 872893185e958eb172ade5eb1772584cab8d8357
https://github.com/qemu/qemu/commit/872893185e958eb172ade5eb1772584cab8d8357
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
A tests/qemu-iotests/tests/loop-create-file
A tests/qemu-iotests/tests/loop-create-file.out
Log Message:
-----------
iotests: add Linux loop device image creation test
This qemu-iotests test case is based on the reproducer that Jean-Louis
Dupond <[email protected]> shared in
https://gitlab.com/qemu-project/qemu/-/issues/3127.
Signed-off-by: Stefan Hajnoczi <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Tested-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 59a1cf0cd31597d2f6e2c18dc400a1de8427d47d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2bb0153cd806b8f6b4f82b353bd0113cd1c488a5
https://github.com/qemu/qemu/commit/2bb0153cd806b8f6b4f82b353bd0113cd1c488a5
Author: Fiona Ebner <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M block/io_uring.c
Log Message:
-----------
block/io_uring: avoid potentially getting stuck after resubmit at the end of
ioq_submit()
Note that this issue seems already fixed as a consequence of the large
io_uring rework with 047dabef97 ("block/io_uring: use aio_add_sqe()")
in current master, so this is purely for QEMU stable branches.
At the end of ioq_submit(), there is an opportunistic call to
luring_process_completions(). This is the single caller of
luring_process_completions() that doesn't use the
luring_process_completions_and_submit() wrapper.
Other callers use the wrapper, because luring_process_completions()
might require a subsequent call to ioq_submit() after resubmitting a
request. As noted for luring_resubmit():
> Resubmit a request by appending it to submit_queue. The caller must ensure
> that ioq_submit() is called later so that submit_queue requests are started.
So the caller at the end of ioq_submit() violates the contract and can
in fact be problematic if no other requests come in later. In such a
case, the request intended to be resubmitted will never be actually be
submitted via io_uring_submit().
A reproducer exposing this issue is [0], which is based on user
reports from [1]. Another reproducer is iotest 109 with '-i io_uring'.
I had the most success to trigger the issue with [0] when using a
BTRFS RAID 1 storage. With tmpfs, it can take quite a few iterations,
but also triggers eventually on my machine. With iotest 109 with '-i
io_uring' the issue triggers reliably on my ext4 file system.
Have ioq_submit() submit any resubmitted requests after calling
luring_process_completions(). The return value from io_uring_submit()
is checked to be non-negative before the opportunistic processing of
completions and going for the new resubmit logic, to ensure that a
failure of io_uring_submit() is not missed. Also note that the return
value already was not necessarily the total number of submissions,
since the loop might've been iterated more than once even before the
current change.
Only trigger the resubmission logic if it is actually necessary to
avoid changing behavior more than necessary. For example iotest 109
would produce more 'mirror ready' events if always resubmitting after
luring_process_completions() at the end of ioq_submit().
Note iotest 109 still does not pass as is when run with '-i io_uring',
because of two offset values for BLOCK_JOB_COMPLETED events being zero
instead of non-zero as in the expected output. Note that the two
affected test cases are expected failures and still fail, so they just
fail "faster". The test cases are actually not triggering the resubmit
logic, so the reason seems to be different ordering of requests and
completions of the current aio=io_uring implementation versus
aio=threads.
[0]:
> #!/bin/bash -e
> #file=/mnt/btrfs/disk.raw
> file=/tmp/disk.raw
> filesize=256
> readsize=512
> rm -f $file
> truncate -s $filesize $file
> ./qemu-system-x86_64 --trace '*uring*' --qmp stdio \
> --blockdev
> raw,node-name=node0,file.driver=file,file.cache.direct=off,file.filename=$file,file.aio=io_uring
> \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "human-monitor-command", "arguments": { "command-line": "qemu-io
> node0 \"read 0 $readsize \"" }}
> {"execute": "quit"}
> EOF
[1]: https://forum.proxmox.com/threads/170045/
Cc: [email protected]
Signed-off-by: Fiona Ebner <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b8f4fee6b495b8ee77148f690e7c599d640a8821
https://github.com/qemu/qemu/commit/b8f4fee6b495b8ee77148f690e7c599d640a8821
Author: Peter Maydell <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/pci/msix.c
M include/hw/pci/msix.h
Log Message:
-----------
hw/pci: Make msix_init take a uint32_t for nentries
msix_init() and msix_init_exclusive_bar() take an "unsigned short"
argument for the number of MSI-X vectors to try to use. This is big
enough for the maximum permitted number of vectors, which is 2048.
Unfortunately, we have several devices (most notably virtio) which
allow the user to specify the desired number of vectors, and which
use uint32_t properties for this. If the user sets the property to a
value that is too big for a uint16_t, the value will be truncated
when it is passed to msix_init(), and msix_init() may then return
success if the truncated value is a valid one.
The resulting mismatch between the number of vectors the msix code
thinks the device has and the number of vectors the device itself
thinks it has can cause assertions, such as the one in issue 2631,
where "-device virtio-mouse-pci,vectors=19923041" is interpreted by
msix as "97 vectors" and by the virtio-pci layer as "19923041
vectors"; a guest attempt to access vector 97 thus passes the
virtio-pci bounds checking and hits an essertion in
msix_vector_use().
Avoid this by making msix_init() and its wrapper function
msix_init_exclusive_bar() take the number of vectors as a uint32_t.
The erroneous command line will now produce the warning
qemu-system-i386: -device virtio-mouse-pci,vectors=19923041:
warning: unable to init msix vectors to 19923041
and proceed without crashing. (The virtio device warns and falls
back to not using MSIX, rather than complaining that the option is
not a valid value this is the same as the existing behaviour for
values that are beyond the MSI-X maximum possible value but fit into
a 16-bit integer, like 2049.)
To ensure this doesn't result in potential overflows in calculation
of the BAR size in msix_init_exclusive_bar(), we duplicate the
nentries error-check from msix_init() at the top of
msix_init_exclusive_bar(), so we know nentries is sane before we
start using it.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2631
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 ef44cc0a762438ebc84c4997a5ce29c6f00622c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19018a95f687d1d03ba3e4438fe97fe82e48a076
https://github.com/qemu/qemu/commit/19018a95f687d1d03ba3e4438fe97fe82e48a076
Author: Peter Xu <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/core/machine.c
Log Message:
-----------
hw/core/machine: Provide a description for aux-ram-share property
It was forgotten when being introduced in commit 91792807d1 ("machine:
aux-ram-share option").
Cc: [email protected]
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Xu <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 98ee8aa92e930a447c6108d4689f0bf8b535359d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 30b8ad835ed664735afdeeedb1f5bbabbaf316f6
https://github.com/qemu/qemu/commit/30b8ad835ed664735afdeeedb1f5bbabbaf316f6
Author: Cédric Le Goater <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/misc/aspeed_xdma.c
M hw/rtc/aspeed_rtc.c
M hw/sd/aspeed_sdhci.c
Log Message:
-----------
hw/aspeed/{xdma, rtc, sdhci}: Fix endianness to DEVICE_LITTLE_ENDIAN
When the XDMA, RTC and SDHCI device models of the Aspeed SoCs were
first introduced, their MMIO regions inherited of a DEVICE_NATIVE_ENDIAN
endianness. It should be DEVICE_LITTLE_ENDIAN. Fix that.
Signed-off-by: Cédric Le Goater <[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 57756aa01fe52c50d655929c43d9a80f8214cf1a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8ecf9dd2740981ee370db803337c073f4bdd900d
https://github.com/qemu/qemu/commit/8ecf9dd2740981ee370db803337c073f4bdd900d
Author: Harald van Dijk <[email protected]>
Date: 2025-12-02 (Tue, 02 Dec 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
target/arm: Fix assert on BRA.
trans_BRA does
gen_a64_set_pc(s, dst);
set_btype_for_br(s, a->rn);
gen_a64_set_pc does
s->pc_save = -1;
set_btype_for_br (if aa64_bti is enabled and the register is not x16 or
x17) does
gen_pc_plus_diff(s, pc, 0);
gen_pc_plus_diff does
assert(s->pc_save != -1);
Hence, this assert is getting hit. We need to call set_btype_for_br
before gen_a64_set_pc, and there is nothing in set_btype_for_br that
depends on gen_a64_set_pc having already been called, so this commit
simply swaps the calls.
(The commit message for 64678fc45d8f6 says that set_brtype_for_br()
must be "moved after" get_a64_set_pc(), but this is a mistake in
the commit message -- the actual changes in that commit move
set_brtype_for_br() *before* get_a64_set_pc() and this is necessary
to avoid the assert.)
Cc: [email protected]
Fixes: 64678fc45d8f6 ("target/arm: Fix BTI versus CF_PCREL")
Signed-off-by: Harald van Dijk <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
[PMM: added note about 64678fc45d8f6 to commit message]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 7248dab3c9d73fcefe609f7a3414f9d048fefcc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ac93de38007cf9531dac75bbf994314007283e82
https://github.com/qemu/qemu/commit/ac93de38007cf9531dac75bbf994314007283e82
Author: Peter Maydell <[email protected]>
Date: 2025-12-02 (Tue, 02 Dec 2025)
Changed paths:
M docs/devel/submitting-a-pull-request.rst
Log Message:
-----------
docs/devel: Update URL for make-pullreq script
In the submitting-a-pull-request docs, we have a link to the
make-pullreq script which might be useful for maintainers. The
canonical git repo for this script has moved; update the link.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-id: [email protected]
(cherry picked from commit ebb625262c7f9837d6c7b9d8a0c1349fe8a8f4ff)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c5ef886100f3af07aeae8239804e33f9bac99bc2
https://github.com/qemu/qemu/commit/c5ef886100f3af07aeae8239804e33f9bac99bc2
Author: Markus Armbruster <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
kvm: Fix kvm_vm_ioctl() and kvm_device_ioctl() return value
These functions wrap ioctl(). When ioctl() fails, it sets @errno.
The wrappers then return that @errno negated.
Except they call accel_ioctl_end() between calling ioctl() and reading
@errno. accel_ioctl_end() can clobber @errno, e.g. when a futex()
system call fails. Seems unlikely, but it's a bug all the same.
Fix by retrieving @errno before calling accel_ioctl_end().
Fixes: a27dd2de68f3 (KVM: keep track of running ioctls)
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 88be119fb19b8ee04d681ad9048cde9f6a37c631)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/d16a8a8e7019...c5ef886100f3
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
