Branch: refs/heads/staging-8.2
Home: https://github.com/qemu/qemu
Commit: c6c7093da0480c8fbfc05d520f279af22fe67977
https://github.com/qemu/qemu/commit/c6c7093da0480c8fbfc05d520f279af22fe67977
Author: Guenter Roeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
scsi: megasas: Internal cdbs have 16-byte length
Host drivers do not necessarily set cdb_len in megasas io commands.
With commits 6d1511cea0 ("scsi: Reject commands if the CDB length
exceeds buf_len") and fe9d8927e2 ("scsi: Add buf_len parameter to
scsi_req_new()"), this results in failures to boot Linux from affected
SCSI drives because cdb_len is set to 0 by the host driver.
Set the cdb length to its actual size to solve the problem.
Signed-off-by: Guenter Roeck <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3abb67323aeecf06a27191076ab50424ec21f334)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: acb95121f34daec74ca40b144df1b4ee5fa72117
https://github.com/qemu/qemu/commit/acb95121f34daec74ca40b144df1b4ee5fa72117
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tests/qtest/libqos/virtio-9p-client.c
Log Message:
-----------
tests/9p: fix Rreaddir response name
All 9p response types are prefixed with an "R", therefore fix
"READDIR" -> "RREADDIR" in function rmessage_name().
Fixes: 4829469fd9ff ("tests/virtio-9p: added readdir test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<daad7af58b403aaa2487c566032beca36664b30e.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit abf0f092c1dd33b9ffa986c6924addc0a9c1d0b8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a635a09f55317f394d5849ce2823999a450b3e42
https://github.com/qemu/qemu/commit/a635a09f55317f394d5849ce2823999a450b3e42
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tests/qtest/libqos/virtio-9p-client.c
Log Message:
-----------
tests/9p: add missing Rgetattr response name
'Tgetattr' 9p request and its 'Rgetattr' response types are already used
by test client, however this response type is yet missing in function
rmessage_name(), so add it.
Fixes: a6821b828404 ("tests/9pfs: compare QIDs in fs_walk_none() test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 4ec984965079b51a9afce339af75edea6de973a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f604ab799a4d29b250b8eaa33e45b3df948d6a71
https://github.com/qemu/qemu/commit/f604ab799a4d29b250b8eaa33e45b3df948d6a71
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tests/qtest/virtio-9p-test.c
Log Message:
-----------
tests/9p: add 'use-after-unlink' test
After removing a file from the file system, we should still be able to
work with the file if we already had it open before removal.
As a first step we verify that it is possible to write to an unlinked
file, as this is what already works. This test is extended later on
after having fixed other use cases after unlink that are not working
yet.
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 462db8fb1d405391b83a0d3099fdb9bfb85c2d92)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: context fix, pick it to stable so the next patch in this place applies)
Commit: a59af26c38ff1b72dd1697111b498e8ed509731b
https://github.com/qemu/qemu/commit/a59af26c38ff1b72dd1697111b498e8ed509731b
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: remove obsolete comment in v9fs_getattr()
The comment claims that we'd only support basic Tgetattr fields. This is
no longer true, so remove this comment.
Fixes: e06a765efbe3 ("hw/9pfs: Add st_gen support in getattr reply")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 3bc4db44430f53387d17145bb52b330a830a03fe)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: pick it to stable so the next commit applies cleanly)
Commit: e2db27e58651520bff7a42d157482ec2ef622005
https://github.com/qemu/qemu/commit/e2db27e58651520bff7a42d157482ec2ef622005
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: fix 'Tgetattr' after unlink
With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.
I.e. this fixes the following misbehaviour with a 9p Linux client:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)
Expected results:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.
Fixes: 00ede4c2529b ("virtio-9p: getattr server implementation...")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit c81e7219e0736f80bfd3553676a19e2992cff41d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bc024c0bb7f36baae2917d1f40a651b43e041aa7
https://github.com/qemu/qemu/commit/bc024c0bb7f36baae2917d1f40a651b43e041aa7
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tests/qtest/virtio-9p-test.c
Log Message:
-----------
tests/9p: also check 'Tgetattr' in 'use-after-unlink' test
This verifies expected behaviour of previous bug fix patch.
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<7017658155c517b9665b75333a97c79aa2d4f3df.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit eaab44ccc59b83d8dff60fca3361a9b98ec7fee6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dec1eee77fc548049c8cb443a1f8176fa0c2d3c4
https://github.com/qemu/qemu/commit/dec1eee77fc548049c8cb443a1f8176fa0c2d3c4
Author: Nicholas Piggin <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M target/ppc/excp_helper.c
Log Message:
-----------
target/ppc: Fix non-maskable interrupt while halted
The ppc (pnv and spapr) NMI injection code does not go through the
asynchronous interrupt path and set a bit in env->pending_interrupts
and raise an interrupt request that the cpu_exec() loop can see.
Instead it injects the exception directly into registers.
This can lead to cpu_exec() missing that the thread has work to do,
if a NMI is injected while it was idle.
Fix this by clearing halted when injecting the interrupt. Probably
NMI injection should be reworked to use the interrupt request interface,
but this seems to work as a minimal fix.
Fixes: 3431648272d3 ("spapr: Add support for new NMI interface")
Reviewed-by: Glenn Miles <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit fa416ae6157a933ad3f7106090684759baaaf3c9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3bc7a671371e24a3655869b261a0a680eca61a33
https://github.com/qemu/qemu/commit/3bc7a671371e24a3655869b261a0a680eca61a33
Author: Klaus Jensen <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix msix_uninit with exclusive bar
Commit fa905f65c554 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.
Cc: [email protected]
Fixes: fa905f65c554 ("hw/nvme: add machine compatibility parameter to enable
msix exclusive bar")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 9162f101257639cc4c7e20f72f77268b1256dd79)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2e10799a7742e65c10816b173d3dc883c79db423
https://github.com/qemu/qemu/commit/2e10799a7742e65c10816b173d3dc883c79db423
Author: Klaus Jensen <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: take a reference on the subsystem on vf realization
Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.
This fixes a latent bug but was not exposed until commit 08f632848008
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad25125b ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee5d1ed, exposing the bug yet again.
Cc: [email protected]
Fixes: 08f632848008 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 6651f8f2e5051f6750c2534ab3151339b3c476a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4532976f7491124ae52742dba036ef7415fb5fe5
https://github.com/qemu/qemu/commit/4532976f7491124ae52742dba036ef7415fb5fe5
Author: Ahmad Fatoum <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/openrisc/openrisc_sim.c
Log Message:
-----------
hw/openrisc/openrisc_sim: keep serial@90000000 as default
We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.
This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.
This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.
Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0. To fix
Linux we fix three things in the device tree:
1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.
In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:
* serial_hd(0) is the lowest-address UART
* serial_hd(0) is listed first in the DTB
* serial_hd(0) is the /chosen/stdout-path one
* the /aliases/serial0 alias points at serial_hd(0)
[1]:
https://lore.barebox.org/barebox/[email protected]/T/#m5da26e8a799033301489a938b5d5667b81cef6ad
Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim")
Cc: [email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
[stafford: Change to serial0 alias and update change message, reverse
uart registration order]
Signed-off-by: Stafford Horne <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
(cherry picked from commit 26dcf2be7e153defa289d20317707af034aca692)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ff48982af2501702bebd6ad05ff1ac7f3a30da04
https://github.com/qemu/qemu/commit/ff48982af2501702bebd6ad05ff1ac7f3a30da04
Author: Peter Maydell <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: Avoid bad shift in riscv_cpu_do_interrupt()
In riscv_cpu_do_interrupt() we use the 'cause' value we got out of
cs->exception as a shift value. However this value can be larger
than 31, which means that "1 << cause" is undefined behaviour,
because we do the shift on an 'int' type.
This causes the undefined behaviour sanitizer to complain
on one of the check-tcg tests:
$ UBSAN_OPTIONS=print_stacktrace=1:abort_on_error=1:halt_on_error=1
./build/clang/qemu-system-riscv64 -M virt -semihosting -display none -device
loader,file=build/clang/tests/tcg/riscv64-softmmu/issue1060
../../target/riscv/cpu_helper.c:1805:38: runtime error: shift exponent 63 is
too large for 32-bit type 'int'
#0 0x55f2dc026703 in riscv_cpu_do_interrupt
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../target/riscv/cpu_helper.c:1805:38
#1 0x55f2dc3d170e in cpu_handle_exception
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../accel/tcg/cpu-exec.c:752:9
In this case cause is RISCV_EXCP_SEMIHOST, which is 0x3f.
Use 1ULL instead to ensure that the shift is in range.
Signed-off-by: Peter Maydell <[email protected]>
Fixes: 1697837ed9 ("target/riscv: Add M-mode virtual interrupt and IRQ
filtering support.")
Fixes: 40336d5b1d ("target/riscv: Add HS-mode virtual interrupt and IRQ
filtering support.")
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 5311599cdc48337f2f27b1b51a80d46d75b05ed0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91c40c5fc2c83bb3761c09977bebabda01a86d8f
https://github.com/qemu/qemu/commit/91c40c5fc2c83bb3761c09977bebabda01a86d8f
Author: Thomas Huth <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/freebsd-13.vars
A .gitlab-ci.d/cirrus/freebsd-14.vars
M tests/lcitool/refresh
M tests/vm/freebsd
Log Message:
-----------
Update FreeBSD CI jobs FreeBSD 14.1
The current FreeBSD CI jobs are failing installation since the
"opencv" package is now missing there. Updating to 14.1 fixes
the issue.
Message-Id: <[email protected]>
Reviewed-by: Li-Wen Hsu <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit b4358ed4fd29c21c69e492d814f0926c58caa10f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f19071da3e64a55afc13c317e6bca0ffeb895d6e
https://github.com/qemu/qemu/commit/f19071da3e64a55afc13c317e6bca0ffeb895d6e
Author: Thomas Huth <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/kvm-build.yml
Log Message:
-----------
.gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs
During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.
Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit cc6cb422e09592158586279fddeef107df05ecbb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d757dd20cbacab124b311f8fe2984946bee54588
https://github.com/qemu/qemu/commit/d757dd20cbacab124b311f8fe2984946bee54588
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/macos-13.vars
M tests/lcitool/refresh
Log Message:
-----------
.gitlab-ci.d/cirrus: Drop support for macOS 13 (Ventura)
macOS 15 "Sequoia" was released on September 16, 2024 [1].
According to QEMU's support policy, we stop supporting
the previous major release two years after the the new
major release has been published. Time to remove support
for macOS 13 (Ventura, released on October 2022, [2]).
Promote the macOS 14 job, which was only built manually,
to be run by default.
[1] https://www.apple.com/newsroom/2024/09/macos-sequoia-is-available-today/
[2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit de11da6448ca4278197fb2923af06c50e2385259)
[thuth: Pick some changes from 9094f7c934, too]
Signed-off-by: Thomas Huth <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 922f8888a06e2431961851593db78aa5a46fd3b9
https://github.com/qemu/qemu/commit/922f8888a06e2431961851593db78aa5a46fd3b9
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M hw/9pfs/9p-util.h
Log Message:
-----------
9pfs: fix regression regarding CVE-2023-2861
The released fix for this CVE:
f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
caused a regression with security_model=passthrough. When handling a
'Tmknod' request there was a side effect that 'Tmknod' request could fail
as 9p server was trying to adjust permissions:
#6 close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140
#7 openat_file (mode=<optimized out>, flags=2228224,
name=<optimized out>, dirfd=<optimized out>) at
../hw/9pfs/9p-util.h:181
#8 fchmodat_nofollow (dirfd=dirfd@entry=31,
name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at
../hw/9pfs/9p-local.c:360
#9 local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0
"mysocket", dirfd=31, fs_ctx=0x55555811f528) at
../hw/9pfs/9p-local.c:457
#10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>,
name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at
../hw/9pfs/9p-local.c:702
#11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140,
fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0,
uid=1000, gid=1000, dev=<optimized out>, mode=49645,
stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205
#12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711
That's because server was opening the special file to adjust permissions,
however it was using O_PATH and it would have not returned the file
descriptor to guest. So the call to close_if_special_file() on that branch
was incorrect.
Let's lift the restriction introduced by f6b0de53fb8 such that it would
allow to open special files on host if O_PATH flag is supplied, not only
for 9p server's own operations as described above, but also for any client
'Topen' request.
It is safe to allow opening special files with O_PATH on host, because
O_PATH only allows path based operations on the resulting file descriptor
and prevents I/O such as read() and write() on that file descriptor.
Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337
Reported-by: Dirk Herrendorfer <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Tested-by: Dirk Herrendorfer <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: afd0838bbcc4e17a3d6cad327288d4b6f27051e1
https://github.com/qemu/qemu/commit/afd0838bbcc4e17a3d6cad327288d4b6f27051e1
Author: Roman Artemev <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tcg/riscv/tcg-target.c.inc
Log Message:
-----------
tcg/riscv: Fix StoreStore barrier generation
On RISC-V to StoreStore barrier corresponds
`fence w, w` not `fence r, r`
Cc: [email protected]
Fixes: efbea94c76b ("tcg/riscv: Add slowpath load and store instructions")
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Denis Tomashev <[email protected]>
Signed-off-by: Roman Artemev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b438362a142527b97b638b7f0f35ebe11911a8d5)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/a1d4a5448a32...afd0838bbcc4
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
