Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Message-ID: <20241219144115.2820241-2-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com>
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Yong-Xuan Wang [Tue, 29 Oct 2024 08:53:47 +0000 (16:53 +0800)]
hw/intc/riscv_aplic: Fix APLIC in_clrip and clripnum write emulation
In the section "4.7 Precise effects on interrupt-pending bits"
of the RISC-V AIA specification defines that:
"If the source mode is Level1 or Level0 and the interrupt domain
is configured in MSI delivery mode (domaincfg.DM = 1):
The pending bit is cleared whenever the rectified input value is
low, when the interrupt is forwarded by MSI, or by a relevant
write to an in_clrip register or to clripnum."
Update the riscv_aplic_set_pending() to match the spec.
Fixes: bf31cf06eb ("hw/intc/riscv_aplic: Fix setipnum_le write emulation for APLIC MSI-mode") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241029085349.30412-1-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 0d0141fadc9063e527865ee420b2baf34e306093) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/i386: Reset TSCs of parked vCPUs too on VM reset
Since commit 5286c3662294 ("target/i386: properly reset TSC on reset")
QEMU writes the special value of "1" to each online vCPU TSC on VM reset
to reset it.
However parked vCPUs don't get that handling and due to that their TSCs
get desynchronized when the VM gets reset.
This in turn causes KVM to turn off PVCLOCK_TSC_STABLE_BIT in its exported
PV clock.
Note that KVM has no understanding of vCPU being currently parked.
Without PVCLOCK_TSC_STABLE_BIT the sched clock is marked unstable in
the guest's kvm_sched_clock_init().
This causes a performance regressions to show in some tests.
Fix this issue by writing the special value of "1" also to TSCs of parked
vCPUs on VM reset.
Reproducing the issue:
1) Boot a VM with "-smp 2,maxcpus=3" or similar
5) Inside the VM run:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is 1.
6) Reboot the VM
7) Once the VM boots once again run inside it:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is now 0.
Thomas Huth [Wed, 18 Dec 2024 06:21:59 +0000 (07:21 +0100)]
meson.build: Disallow libnfs v6 to fix the broken macOS build
The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).
Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.
Message-ID: <20241218065157.209020-1-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Fri, 13 Dec 2024 18:23:37 +0000 (18:23 +0000)]
hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs
In the GICv3 ITS model, we have a common coding pattern which has a
local C struct like "DTEntry dte", which is a C representation of an
in-guest-memory data structure, and we call a function such as
get_dte() to read guest memory and fill in the C struct. These
functions to read in the struct sometimes have cases where they will
leave early and not fill in the whole struct (for instance get_dte()
will set "dte->valid = false" and nothing else for the case where it
is passed an entry_addr implying that there is no L2 table entry for
the DTE). This then causes potential use of uninitialized memory
later, for instance when we call a trace event which prints all the
fields of the struct. Sufficiently advanced compilers may produce
-Wmaybe-uninitialized warnings about this, especially if LTO is
enabled.
Rather than trying to carefully separate out these trace events into
"only the 'valid' field is initialized" and "all fields can be
printed", zero-init all the structs when we define them. None of
these structs are large (the biggest is 24 bytes) and having
consistent behaviour is less likely to be buggy.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241213182337.3343068-1-peter.maydell@linaro.org
(cherry picked from commit 9678b9c505725732353baefedb88b53c2eb8a184) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When allocating new temps during tcg_optmize, do not re-use
any EBB temps that were used within the TB. We do not have
any idea what span of the TB in which the temp was live.
Introduce tcg_temp_ebb_reset_freed and use before tcg_optimize,
as well as replacing the equivalent in plugin_gen_inject and
tcg_func_start.
Cc: qemu-stable@nongnu.org Fixes: fb04ab7ddd8 ("tcg/optimize: Lower TCG_COND_TST{EQ,NE} if unsupported")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2711 Reported-by: wannacu <wannacu2049@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 04e006ab36a8565b92d4e21dd346367fbade7d74) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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 <d.herrendoerfer@de.ibm.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Dirk Herrendorfer <d.herrendoerfer@de.ibm.com>
Message-Id: <E1tJWbk-007BH4-OB@kylie.crudebyte.com>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* tag 'hw-misc-20241203' of https://github.com/philmd/qemu:
system: Select HVF by default when no other accelerator is available
tests/qtest: add test for querying balloon guest stats
tests/qtest: drop 'fuzz-' prefix from virtio-balloon test
hw/virtio: fix crash in processing balloon stats
hw/display/vga: Do not reset 'big_endian_fb' in vga_common_reset()
target/riscv: Avoid bad shift in riscv_cpu_do_interrupt()
hw/core/machine: diagnose wrapping of maxmem
MAINTAINERS: update email addr for Brian Cain
meson: Add missing SDL dependency to system/main.c
MAINTAINERS: add myself as the maintainer for LoongArch VirtMachine
ui/cocoa: Temporarily ignore annoying deprecated declaration warnings
hw/openrisc/openrisc_sim: keep serial@90000000 as default
hw/openrisc: Fixed undercounting of TTCR in continuous mode
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 3 Dec 2024 13:43:57 +0000 (13:43 +0000)]
Merge tag 'pull-or1k-20241203' of https://github.com/stffrdhrn/qemu into staging
OpenRISC updates for 9.2.0
This series has 2 fixes:
- Fix to keep serial@90000000 as default
- Fixed undercounting of TTCR in continuous mode
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE2cRzVK74bBA6Je/xw7McLV5mJ+QFAmdO56EACgkQw7McLV5m
# J+T8BRAAxZMH4ykdRJBmYiFVOsYKagcdT6GGBHL44FGeQSr1lNyoU0Rn5r6v5GHe
# Nwq7DTeZlKoVji5GXki53mGrwENXr00m+xfc9ACMoWr5IM6McQUPXlQAQ/50fIGs
# lzXMZH/4EdPIVkkpCi+y8FLYw02oQg61U9G0HW02lQJy4Y4mudtvQFGzJ7f3SIZ3
# EkKn5YLG0bqszq/amFNLQXlbnq3yI5zfcMHhHx0KuDsm2yNhrNA+AJP8tLI3JlxL
# +0YIA+fWuxQzz8Zu9+ckc8VAV83HIgQpXVzI6rQxdSwbmRgUu9ITO09ZmxaDHZF6
# sDI6K3VouyaHJVkvu4coDajpYTjHLE26c9LAlaVBpgdnmnYy4vlndEqbfaBqOouX
# n0N2wJ3IGouIw7AnB9dTaZhM/Uo09hZKDr6kCm3hLfPn2+vi3yxsbwVwLaOpH3G3
# kQ5ZFKjoA7XWOaXGOUMcmhByXkSxja+pSBppB58vJAFyVp73HYIpea3/q1Zd8S4S
# noJoqxDtD2zf26bDBIe83pUEnSnL8fAcsh3rlQP8HrWYhU7ZulVSE1ZvPkPgDpkY
# LVCPautTElsMp2Mg4a2oODGvSDN4/5h2dp6TaK4Qep92HHFOwPZQBQW607VwWR5N
# II8dB/l8PluKkgZ3ymhP1p9JAAZFe9a2cMmegRIiM74PkPty0kk=
# =guIi
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 03 Dec 2024 11:12:33 GMT
# gpg: using RSA key D9C47354AEF86C103A25EFF1C3B31C2D5E6627E4
# gpg: Good signature from "Stafford Horne <shorne@gmail.com>" [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: D9C4 7354 AEF8 6C10 3A25 EFF1 C3B3 1C2D 5E66 27E4
* tag 'pull-or1k-20241203' of https://github.com/stffrdhrn/qemu:
hw/openrisc: Fixed undercounting of TTCR in continuous mode
hw/openrisc/openrisc_sim: keep serial@90000000 as default
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nicholas Piggin [Wed, 28 Aug 2024 04:33:34 +0000 (14:33 +1000)]
chardev: Fix record/replay error path NULL deref in device creation
qemu_chardev_set_replay() was being called in chardev creation to
set up replay parameters even if the chardev is NULL.
A segfault can be reproduced by specifying '-serial chardev:bad' with
an rr=record mode.
Fix this with a NULL pointer check.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Resolves: Coverity CID 1559470 Fixes: 4c193bb129dae ("chardev: set record/replay on the base device of a muxed device") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20240828043337.14587-2-npiggin@gmail.com>
system: Select HVF by default when no other accelerator is available
When testing with a HVF-only binary, we get:
3/12 qemu:func-quick+func-aarch64 / func-aarch64-version ERROR 0.29s exit status 1
stderr:
Traceback (most recent call last):
File "tests/functional/test_version.py", line 22, in test_qmp_human_info_version
self.vm.launch()
File "machine/machine.py", line 461, in launch
raise VMLaunchFailure(
qemu.machine.machine.VMLaunchFailure: ConnectError: Failed to establish session: EOFError
Exit code: 1
Command: build/qemu-system-aarch64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -machine none -nodefaults
Output: qemu-system-aarch64: No accelerator selected and no default accelerator available
Fix by checking for HVF in configure_accelerators() and using
it by default when no other accelerator is available.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20241203094232.62232-1-philmd@linaro.org>
tests/qtest: add test for querying balloon guest stats
This test would have identified the crash caused by the addition of new
balloon stats fields.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20241129135507.699030-4-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
tests/qtest: drop 'fuzz-' prefix from virtio-balloon test
This test file is expected to be extended for arbitrary virtio-balloon
related tests, not merely those discovered by fuzzing.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20241129135507.699030-3-berrange@redhat.com>
[PMD: Update MAINTAINERS] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com>
balloon_stats_get_all will iterate over guest stats upto the max
VIRTIO_BALLOON_S_NR value, calling visit_type_uint64 to populate
the QObject dict. The dict keys are obtained from the static
array balloon_stat_names which is VIRTIO_BALLOON_S_NR in size.
Unfortunately the way that array is declared results in any
unassigned stats getting a NULL name, which will then cause
visit_type_uint64 to trigger an assert in qobject_output_add_obj.
The balloon_stat_names array was fortunately fully populated with
names until recently:
pulled a change to include/standard-headers/linux/virtio_balloon.h
which increased VIRTIO_BALLOON_S_NR by 6, and failed to add the new
names to balloon_stat_names.
This commit fills in the missing names, and uses a static assert to
guarantee that any future changes to VIRTIO_BALLOON_S_NR will cause
a build failure until balloon_stat_names is updated.
This problem was detected by the Cockpit Project's automated
integration tests on QEMU 9.2.0-rc1.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2329448 Fixes: 0d2eeef77a3 ("linux-headers: Update to Linux v6.12-rc5") Reported-by: Martin Pitt <mpitt@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20241129135507.699030-2-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
hw/display/vga: Do not reset 'big_endian_fb' in vga_common_reset()
The 'pci-vga' device allow setting a 'big-endian-framebuffer'
property since commit 3c2784fc864 ("vga: Expose framebuffer
byteorder as a QOM property"). Similarly, the 'virtio-vga'
device since commit 8be61ce2ce3 ("virtio-vga: implement
big-endian-framebuffer property").
Both call vga_common_reset() in their reset handler, respectively
pci_secondary_vga_reset() and virtio_vga_base_reset_hold(), which
reset 'big_endian_fb', overwritting the property. This is not
correct: the hardware is expected to keep its configured
endianness during resets.
Move 'big_endian_fb' assignment from vga_common_reset() to
vga_common_init() which is called once when the common VGA state
is initialized.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Message-Id: <20241129101721.17836-2-philmd@linaro.org>
Peter Maydell [Thu, 28 Nov 2024 10:38:31 +0000 (10:38 +0000)]
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 <peter.maydell@linaro.org> 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 <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241128103831.3452572-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The 'maxmem' parameter parsed on the command line is held in uint64_t
and then assigned to the MachineState field that is 'ram_addr_t'. This
assignment will wrap on 32-bit hosts, silently changing the user's
config request if it were over-sized.
Improve the existing diagnositics for validating 'size', and add the
same diagnostics for 'maxmem'
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20241127114057.255995-1-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Brian Cain [Sat, 23 Nov 2024 16:46:40 +0000 (08:46 -0800)]
MAINTAINERS: update email addr for Brian Cain
Also: add mapping for "quic_bcain@quicinc.com" which was ~briefly
used for some replies to mailing list traffic.
Signed-off-by: Brian Cain <bcain@quicinc.com> Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241123164641.364748-2-bcain@quicinc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
meson: Add missing SDL dependency to system/main.c
When building QEMU configure with --disable-gtk --disable-cocoa
on macOS we get:
User interface
Cocoa support : NO
SDL support : YES 2.30.5
SDL image support : NO
GTK support : NO
pixman : YES 0.42.2
VTE support : NO
PNG support : YES 1.6.43
VNC support : YES
VNC SASL support : YES
VNC JPEG support : YES 3.0.3
spice protocol support : YES 0.14.4
spice server support : NO
curses support : YES
brlapi support : NO
User defined options
cocoa : disabled
docs : disabled
gtk : disabled
../system/main.c:30:10: fatal error: 'SDL.h' file not found
30 | #include <SDL.h>
| ^~~~~~~
1 error generated.
Fix by adding the SDL dependency to main.c it's CFLAGS contains
the SDL include directory.
Fixes: 64ed6f92ff ("meson: link emulators without Makefile.target") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20241120114943.85080-1-philmd@linaro.org>
Bibo Mao [Tue, 12 Nov 2024 07:37:14 +0000 (15:37 +0800)]
MAINTAINERS: add myself as the maintainer for LoongArch VirtMachine
Song Gao is will be sick leave for a long time, I apply for maintainer
for LoongArch Virt Machine during this period, LoongArch TCG keeps unchanged
since I am not familiar with it. The maintainer duty will transfer to him
after he comes back to work.
Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241112073714.1953481-1-maobibo@loongson.cn> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
These warnings are breaking some build configurations since 2 months
now (https://gitlab.com/qemu-project/qemu/-/issues/2575):
ui/cocoa.m:662:14: error: 'CVDisplayLinkCreateWithCGDisplay' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
662 | if (!CVDisplayLinkCreateWithCGDisplay(display, &displayLink)) {
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:89:20: note: 'CVDisplayLinkCreateWithCGDisplay' has been explicitly marked deprecated here
89 | CV_EXPORT CVReturn CVDisplayLinkCreateWithCGDisplay(
| ^
ui/cocoa.m:663:29: error: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
663 | CVTime period = CVDisplayLinkGetNominalOutputVideoRefreshPeriod(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:182:18: note: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' has been explicitly marked deprecated here
182 | CV_EXPORT CVTime CVDisplayLinkGetNominalOutputVideoRefreshPeriod( CVDisplayLinkRef CV_NONNULL displayLink );
| ^
ui/cocoa.m:664:13: error: 'CVDisplayLinkRelease' is deprecated: first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:), or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
664 | CVDisplayLinkRelease(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:249:16: note: 'CVDisplayLinkRelease' has been explicitly marked deprecated here
249 | CV_EXPORT void CVDisplayLinkRelease( CV_RELEASES_ARGUMENT CVDisplayLinkRef CV_NULLABLE displayLink );
| ^
3 errors generated.
For the next release, ignore the warnings using #pragma directives.
At least until we figure the correct new API usage.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu> Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>
Message-Id: <20241121131954.98949-1-philmd@linaro.org>
Ahmad Fatoum [Thu, 22 Aug 2024 16:38:38 +0000 (18:38 +0200)]
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)
[stafford: Change to serial0 alias and update change message, reverse
uart registration order]
Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim") Cc: qemu-stable@nongnu.org Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20241203110536.402131-2-shorne@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Joel Holdsworth [Fri, 7 Jun 2024 22:29:33 +0000 (15:29 -0700)]
hw/openrisc: Fixed undercounting of TTCR in continuous mode
In the existing design, TTCR is prone to undercounting when running in
continuous mode. This manifests as a timer interrupt appearing to
trigger a few cycles prior to the deadline set in SPR_TTMR_TP.
When the timer triggers, the virtual time delta in nanoseconds between
the time when the timer was set, and when it triggers is calculated.
This nanoseconds value is then divided by TIMER_PERIOD (50) to compute
an increment of cycles to apply to TTCR.
However, this calculation rounds down the number of cycles causing the
undercounting.
A simplistic solution would be to instead round up the number of cycles,
however this will result in the accumulation of timing error over time.
This patch corrects the issue by calculating the time delta in
nanoseconds between when the timer was last reset and the timer event.
This approach allows the TTCR value to be rounded up, but without
accumulating error over time.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
[stafford: Incremented version in vmstate_or1k_timer, checkpatch fixes] Signed-off-by: Stafford Horne <shorne@gmail.com>
Message-ID: <20241203110536.402131-3-shorne@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Joel Holdsworth [Fri, 7 Jun 2024 22:29:33 +0000 (15:29 -0700)]
hw/openrisc: Fixed undercounting of TTCR in continuous mode
In the existing design, TTCR is prone to undercounting when running in
continuous mode. This manifests as a timer interrupt appearing to
trigger a few cycles prior to the deadline set in SPR_TTMR_TP.
When the timer triggers, the virtual time delta in nanoseconds between
the time when the timer was set, and when it triggers is calculated.
This nanoseconds value is then divided by TIMER_PERIOD (50) to compute
an increment of cycles to apply to TTCR.
However, this calculation rounds down the number of cycles causing the
undercounting.
A simplistic solution would be to instead round up the number of cycles,
however this will result in the accumulation of timing error over time.
This patch corrects the issue by calculating the time delta in
nanoseconds between when the timer was last reset and the timer event.
This approach allows the TTCR value to be rounded up, but without
accumulating error over time.
Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
[stafford: Incremented version in vmstate_or1k_timer, checkpatch fixes] Signed-off-by: Stafford Horne <shorne@gmail.com>
Ahmad Fatoum [Thu, 22 Aug 2024 16:38:38 +0000 (18:38 +0200)]
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)
Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim") Cc: qemu-stable@nongnu.org Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
[stafford: Change to serial0 alias and update change message, reverse
uart registration order] Signed-off-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
* tag 'pull-nvme-20241203' of https://gitlab.com/birkelund/qemu:
hw/nvme: take a reference on the subsystem on vf realization
hw/nvme: SR-IOV VFs must hardwire pci interrupt pin register to zero
hw/nvme: fix use/unuse of msix vectors
hw/nvme: fix msix_uninit with exclusive bar
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Klaus Jensen [Mon, 11 Nov 2024 11:14:49 +0000 (12:14 +0100)]
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: qemu-stable@nongnu.org Fixes: 08f632848008 ("pcie: Release references of virtual functions") Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Klaus Jensen [Sun, 10 Nov 2024 13:04:27 +0000 (14:04 +0100)]
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.
* tag 'pull-request-2024-12-02' of https://gitlab.com/thuth/qemu:
tests/functional: increase timeouts for arm sx1 test
tests/functional/test_virtio_version: Check for the availability of the machine
tests/functional/test_acpi_bits: Turn the test into a QemuSystemTest
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
tests/functional: increase timeouts for arm sx1 test
When under high load the test VM does not complete running in the
default 30 second timeout. Double it to give more headroom.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20241129173120.761728-2-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Thu, 28 Nov 2024 12:01:42 +0000 (13:01 +0100)]
tests/functional/test_virtio_version: Check for the availability of the machine
Use self_set_machine() to set and check for the availability of the
default pc machine (so that the test is not failing if the machine
has not been included in the QEMU binary).
Message-ID: <20241128120142.593408-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Thu, 28 Nov 2024 11:50:19 +0000 (12:50 +0100)]
tests/functional/test_acpi_bits: Turn the test into a QemuSystemTest
By using QemuSystemTest as a base class, we can use the set_machine()
command to check whether the required machine is available in the
binary (otherwise this test is failing when QEMU has been compiled
without the default 'pc' machine type).
Message-ID: <20241128115019.591362-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
* tag 'chr-pull-request' of https://gitlab.com/marcandre.lureau/qemu:
chardev/char-mux: make boolean bit check instead of find_next_bit()
chardev/char-mux: shift unsigned long to avoid 32-bit overflow
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
scsi: megasas: Internal cdbs have 16-byte length
hvf: complete 1G page support
amd_iommu: Fix kvm_enable_x2apic link error with clang in non-KVM builds
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 29 Nov 2024 10:08:53 +0000 (10:08 +0000)]
Merge tag 'pull-9p-20241128' of https://github.com/cschoenebeck/qemu into staging
* Fix open-unlink-fstat idiom on Linux guests.
* Add test to verify this behaviour.
* Cleanup patches.
# -----BEGIN PGP SIGNATURE-----
#
# iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmdIvDkXHHFlbXVfb3Nz
# QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5X8ixAApDPStDxYf1CGdLirInHGp77i
# 0MlBsuaP00f8bZyCLJCFgax2+ogXD72Ptw2thDDMtkMsg9lqZwOtG5I4cJGC3TK2
# J4ZXpg/mg0bY+4o2gvnyeKv8BFl5wE91pdIeFX8ufQ+L2WE+fasWOn38TFB/T/8Z
# 1naN4A8Mu5F9myJ+F6pIYlJfkgbZniNib9BgSMG8pYI6uayWD+YVjR139ozWCf1c
# vhFFpLrwW4j3DOC0WblghQmiMwhXo1QxNAEq0x31/eoD1+calJAwhWsLWksuVIqR
# 6wbGPfNVozgk9l7owYB5Gams5zVJRfLD5LCAitUx2qqMMzxuD3QldLjOmFA/8XdG
# +2/ROBeXJ51blCAMFdp9IwTKzimvuWVL3kXbcQ3n+D459iBZzqW+9w4EYVYShpp6
# uwAAkW9fwVR/U7ERG3n8D6Cw1B9Scvtjksw/VCe9XUNFp6H66K/OXy8NFmnZZk9K
# K9SYkKOVixwZDqMoGoLsoxx0DbakYL+lBYrl6qVZUPRLOjJ+JvLAoblJ0ZmUgsl2
# lXG7vO96+LyRvVjqPoi2D7+MHrmFoeRgWjzZqFqWOakXBHCKcCEVzpAoB4eYyQrj
# rXC5BNhdu9yIa7Dy7V6tFoXPdN1is90bJs92DYTsOG1KdU2DviAUSZk4MjTJzQWN
# 3fvOcZPFq74228CWrN4=
# =XP1U
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 28 Nov 2024 18:53:45 GMT
# gpg: using RSA key 96D8D110CF7AF8084F88590134C2B58765A47395
# gpg: issuer "qemu_oss@crudebyte.com"
# gpg: Good signature from "Christian Schoenebeck <qemu_oss@crudebyte.com>" [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: ECAB 1A45 4014 1413 BA38 4926 30DB 47C3 A012 D5F4
# Subkey fingerprint: 96D8 D110 CF7A F808 4F88 5901 34C2 B587 65A4 7395
* tag 'pull-9p-20241128' of https://github.com/cschoenebeck/qemu:
tests/9p: also check 'Tgetattr' in 'use-after-unlink' test
9pfs: fix 'Tgetattr' after unlink
9pfs: remove obsolete comment in v9fs_getattr()
tests/9p: add missing Rgetattr response name
tests/9p: fix Rreaddir response name
tests/9p: add 'use-after-unlink' test
9pfs: cleanup V9fsFidState
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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)
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 <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com>
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 <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_oss@crudebyte.com>
'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 <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_oss@crudebyte.com>
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.
Drop V9fsFidState's 'next' member, which is no longer used since:
f5265c8f917e ('9pfs: use GHashTable for fid table')
Fixes: f5265c8f917e ('9pfs: use GHashTable for fid table') Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1tE4v2-0051EH-Ni@kylie.crudebyte.com>
Guenter Roeck [Tue, 28 Feb 2023 17:11:29 +0000 (09:11 -0800)]
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.
Alexander Graf [Thu, 20 Apr 2023 22:52:58 +0000 (00:52 +0200)]
hvf: complete 1G page support
Hvf on x86 only supported 2MiB large pages, but never bothered to strip
out the 1GiB page size capability from -cpu host. With QEMU 8.0.0 this
became a problem because OVMF started to use 1GiB pages by default.
Let's just unconditionally add 1GiB page walk support to the walker.
With this fix applied, I can successfully run OVMF again.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1603 Signed-off-by: Alexander Graf <agraf@csgraf.de> Reported-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp> Reported-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu> Link: https://lore.kernel.org/r/20230420225258.58009-1-agraf@csgraf.de Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Sairaj Kodilkar [Thu, 14 Nov 2024 11:45:09 +0000 (17:15 +0530)]
amd_iommu: Fix kvm_enable_x2apic link error with clang in non-KVM builds
Commit b12cb3819 (amd_iommu: Check APIC ID > 255 for XTSup) throws
linking error for the `kvm_enable_x2apic` when kvm is disabled
and Clang is used for compilation.
This issue comes up because Clang does not remove the function callsite
(kvm_enable_x2apic in this case) during optimization when if condition
have variable. Intel IOMMU driver solves this issue by creating separate
if condition for checking variables, which causes call site being
optimized away by virtue of `kvm_irqchip_is_split()` being defined as 0.
Implement same solution for the AMD driver.
Fixes: b12cb3819baf (amd_iommu: Check APIC ID > 255 for XTSup) Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Signed-off-by: Santosh Shukla <santosh.shukla@amd.com> Tested-by: Phil Dennis-Jordan <phil@philjordan.eu> Link: https://lore.kernel.org/r/20241114114509.15350-1-sarunkod@amd.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell [Thu, 28 Nov 2024 10:50:20 +0000 (10:50 +0000)]
Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging
virtio,pc,pci: bug fixes, new test
Some small bug fixes, notably a fix for a regression
in cpu hotplug after migration. I also included a
new test, just to help make sure we don't regress cxl.
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu:
vhost: fail device start if iotlb update fails
bios-tables-test: Add data for complex numa test (GI, GP etc)
bios-tables-test: Add complex SRAT / HMAT test for GI GP
bios-tables-test: Allow for new acpihmat-generic-x test data.
qapi/qom: Change Since entry for AcpiGenericPortProperties to 9.2
hw/acpi: Fix size of HID in build_append_srat_acpi_device_handle()
qapi: fix device-sync-config since-version
hw/cxl: Check for zero length features in cmd_features_set_feature()
tests/acpi: update expected blobs
Revert "hw/acpi: Make CPUs ACPI `presence` conditional during vCPU hot-unplug"
Revert "hw/acpi: Update ACPI `_STA` method with QOM vCPU ACPI Hotplug states"
qtest: allow ACPI DSDT Table changes
vhost_net: fix assertion triggered by batch of host notifiers processing
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Wed, 27 Nov 2024 13:35:54 +0000 (13:35 +0000)]
Merge tag 'pull-request-2024-11-27' of https://gitlab.com/thuth/qemu into staging
* Two small doc updates
* Fix the flaky loongarch64 and sh4 functional tests
* Refuse to compile with old XCode versions that don't work anymore
* Remove an unused function from PCI code
* tag 'pull-request-2024-11-27' of https://gitlab.com/thuth/qemu:
hw/pci: Remove unused pci_irq_pulse() method
tests/functional: Remove sleep workarounds from sh4 test
.gitlab-ci.d/cirrus: Remove the wrong CPU and RAM settings from the macOS job
meson.build: Refuse XCode versions < v15.0
tests/functional: Fix the running test case causes loongarch64 to hang
docs: Document that hvf on Arm is supported
docs/devel/testing/functional: Clarify that we have to use the build folder
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Last use of pci_irq_pulse() was removed 7 years ago in commit 5e9aa92eb1 ("hw/block: Fix pin-based interrupt behaviour of NVMe").
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241122103418.539-1-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Cédric Le Goater [Fri, 22 Nov 2024 14:18:27 +0000 (15:18 +0100)]
tests/functional: Remove sleep workarounds from sh4 test
These were introduced in the avocado tests to workaround read issues
when interacting with console. They are no longer necessary and we can
use the expected login string instead.
Test always passes now. Remove skipUnless test on QEMU_TEST_FLAKY_TESTS.
Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241122141827.2039984-1-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Mon, 25 Nov 2024 12:43:42 +0000 (13:43 +0100)]
.gitlab-ci.d/cirrus: Remove the wrong CPU and RAM settings from the macOS job
The macOS runner ignores them and always uses 4 CPUs and 12 GiB of
RAM, so remove our setting to avoid wrong expectations.
Message-ID: <20241125124342.187594-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Tue, 26 Nov 2024 08:10:54 +0000 (09:10 +0100)]
meson.build: Refuse XCode versions < v15.0
According to our support policy, we only support the two latest
major versions of macOS, and we already removed compatibility code
for older versions. However, it's still possible that people install
an older version of XCode on a recent version of macOS - which won't
be able to compile QEMU anymore, see for example the ticket here:
Thus let's set the expectations right and refuse older versions of
XCode that do not match the two latest versions of macOS anymore.
Message-ID: <20241126081054.244365-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Xianglai Li [Wed, 27 Nov 2024 01:34:38 +0000 (09:34 +0800)]
tests/functional: Fix the running test case causes loongarch64 to hang
There is a bug in the process of resolving the serial port base address
in the fdt of the loongarch VM UEFI. When both serial port information
and rng-seed information are chosen in the fdt, there is a probability
that the serial port base address cannot be resolved correctly.
This problem can be fixed by updating UEFI.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2686 Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Message-ID: <20241127013438.2206426-1-lixianglai@loongson.cn> Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Thomas Huth [Tue, 12 Nov 2024 11:53:02 +0000 (12:53 +0100)]
docs/devel/testing/functional: Clarify that we have to use the build folder
Make it clear that the commands have to be run from the folder with the
build, and use the python3 from our pyvenv to make sure that the
pycotap module is available.
Message-ID: <20241112115302.470527-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Prasad Pandit [Thu, 7 Nov 2024 11:32:47 +0000 (17:02 +0530)]
vhost: fail device start if iotlb update fails
While starting a vhost device, updating iotlb entries
via 'vhost_device_iotlb_miss' may return an error.
qemu-kvm: vhost_device_iotlb_miss:
700871,700871: Fail to update device iotlb
Fail device start when such an error occurs.
Signed-off-by: Prasad Pandit <pjp@fedoraproject.org>
Message-Id: <20241107113247.46532-1-ppandit@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
bios-tables-test: Add data for complex numa test (GI, GP etc)
Given this is a new configuration, there are affects on APIC, CEDT
and DSDT, but the key elements are in SRAT (plus related data in
HMAT). The configuration has node to exercise many different combinations.
0) CPUs + Memory
1) GI only
2) GP only
3) CPUS only
4) Memory only
5) CPUs + HP memory
GI node, GP Node, Memory only node, hotplug memory
only node, latency and bandwidth such that in Linux Access0
(any initiator) and Access1 (CPU initiators only) given different
answers. Following cropped to remove details of each entry.
Note the zeros represent entries where the target node has no
memory. These could be surpressed but it isn't 'wrong' to provide
them and it is (probably) permissible under ACPI to hotplug memory
into these nodes later.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241107123446.902801-6-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
bios-tables-test: Add complex SRAT / HMAT test for GI GP
Add a test with 6 nodes to exercise most interesting corner cases of SRAT
and HMAT generation including the new Generic Initiator and Generic Port
Affinity structures. More details of the set up in the following patch
adding the table data.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241107123446.902801-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
bios-tables-test: Allow for new acpihmat-generic-x test data.
The test to be added exercises many corner cases of the SRAT and HMAT table
generation.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241107123446.902801-4-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
qapi/qom: Change Since entry for AcpiGenericPortProperties to 9.2
This feature was only applied during the 9.2 cycle, so reflect
that rather than 9.1.
Reported-by: Daniel P. Berrangé <berrange@redhat.com> Closes: https://lore.kernel.org/qemu-devel/ZyngEiwmYeZ-DvCy@redhat.com/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241107123446.902801-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
hw/acpi: Fix size of HID in build_append_srat_acpi_device_handle()
The size should always be 8 so hard code that. By coincidience the
incorrect use of sizeof(char *) is 8 on 64 bit hosts, but was caught
by CI testing with i686 as the host.
Reported-by: Michael S. Tsirkin <mst@redhat.com> Closes: https://lore.kernel.org/qemu-devel/20241104110025-mutt-send-email-mst@kernel.org/ Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241107123446.902801-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Fixes: 3f98408e2e ("qapi: introduce device-sync-config") Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20241108071957.727286-1-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/cxl: Check for zero length features in cmd_features_set_feature()
Zero length data for features doesn't make any sense so exclude that case
early. This fixes the undefined behavior reported by coverity for a zero
length memcpy().
Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20241108175814.1248278-1-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Igor Mammedov [Tue, 12 Nov 2024 17:02:55 +0000 (18:02 +0100)]
tests/acpi: update expected blobs
Expected AML return to the state before bf1ecc8dad606 (w/acpi: Update ACPI `_STA` method with QOM vCPU ACPI Hotplug states)
droping not needed CPRS and _STA logic that broke cpu hotplug
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20241112170258.2996640-5-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The patch is supposed to be part of ARM CPU hotplug series and has not value
on its own without it. The series however is still in RFC stage and outside
of scope 9.2 release.
On top of that it introduces not needed callback that pokes directly into
CPU state without any need for that. Instead properties and AML generator
option should be used to configure static platform depended vCPU presence
state.
Drop the patch so that corrected version could be posted along with
ARM CPU hotplug series and properly reviewed in relevant context.
That also helps us to keep history cleaner with new patch being
against original code vs a string of fixups on top of current mess.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20241112170258.2996640-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fixes: bf1ecc8dad606 (w/acpi: Update ACPI `_STA` method with QOM vCPU ACPI Hotplug states) Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20241112170258.2996640-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Salil Mehta [Tue, 12 Nov 2024 17:02:52 +0000 (18:02 +0100)]
qtest: allow ACPI DSDT Table changes
list changed files in tests/qtest/bios-tables-test-allowed-diff.h
Message-ID: <20241106100047.18901c9d@imammedo.users.ipa.redhat.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20241112170258.2996640-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
zuoboqun [Fri, 15 Nov 2024 08:03:12 +0000 (16:03 +0800)]
vhost_net: fix assertion triggered by batch of host notifiers processing
When the backend of vhost_net restarts during the vm is running, vhost_net
is stopped and started. The virtio_device_grab_ioeventfd() fucntion in
vhost_net_enable_notifiers() will result in a call to
virtio_bus_set_host_notifier()(assign=false).
And now virtio_device_grab_ioeventfd() is batched in a single transaction
with virtio_bus_set_host_notifier()(assign=true).
This triggers the following assertion:
kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor
This patch moves virtio_device_grab_ioeventfd() out of the batch to fix
this problem.
To be noted that the for loop to release ioeventfd should start from i+1,
not i, because the i-th ioeventfd has already been released in
vhost_dev_disable_notifiers_nvqs().
Fixes: 6166799f6 ("vhost_net: configure all host notifiers in a single MR transaction") Signed-off-by: Zuo Boqun <zuoboqun@baidu.com> Reported-by: Gao Shiyuan <gaoshiyuan@baidu.com>
Message-Id: <20241115080312.3184-1-zuoboqun@baidu.com> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Peter Maydell [Tue, 26 Nov 2024 20:16:26 +0000 (20:16 +0000)]
Merge tag 'pull-ppc-for-9.2-2-20241127' of https://gitlab.com/npiggin/qemu into staging
* Assorted small ppc fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEETkN92lZhb0MpsKeVZ7MCdqhiHK4FAmdF/gUACgkQZ7MCdqhi
# HK55/xAAw1AXhd+B9JODn6bpDzIvG1yZN81X7xm5WtVQwb9GgBlacBMgVRZQvulX
# 0TH0GBe2/+NkIgr/8c2j2NN3VwME86w56R7E9XFStwh9Q+80vJNT898023gAeN7k
# qiy+XBroUBkJJhuJOYXMCsgg7j0eTaCdVJxqytKBtr4vQnxRfkgKLeHKyMSF0uNu
# geRg76V3elleDNIhSood8GJ/O+Boom9Dvrsj7FwxIfTRnT8d1cwUV599fOJMYW/A
# EOquM54eREhCymVOMTx3gpJAMQXMGJ9LKR6AuIWEu1t4J9KJD27I5a56ASjz8BcO
# RH6DeqDVSauv25NqWKk4388xYTzd1zTScG4X7qdLcoLwy+wjyB90mvbLFmpuNjrG
# bR5BALRF0OtJ2SQ+DHM8h0OPQANl33c0YCU5GHMsFMiAkPJPaZWib1VrzeU8JzjW
# nUbKPE6htYh6Ee6dyGq/E1SP7QgmJTavZ/aY8j5e5iyJBWEZuS80TZ8FYv6ETFp7
# 5SHpRcvREZs4GO8vWwh8yNuepvQ5O6iK79kQUjcdREvRjT419m50cfJwyMxhG16r
# IeNkny7YtfX7s90s8zhw3WQECmBpfKqvzXtFZPORdge2MJSHFmYpnip9uLp1r1pU
# 1BUe1m1vubqd6/2JLw0FLIIqjuEv9VLDh4HI6ehG/7G7gwnwlRc=
# =Acg2
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 26 Nov 2024 16:57:41 GMT
# gpg: using RSA key 4E437DDA56616F4329B0A79567B30276A8621CAE
# gpg: Good signature from "Nicholas Piggin <npiggin@gmail.com>" [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: 4E43 7DDA 5661 6F43 29B0 A795 67B3 0276 A862 1CAE
* tag 'pull-ppc-for-9.2-2-20241127' of https://gitlab.com/npiggin/qemu:
hw/ppc/pegasos2: Fix IRQ routing from pci.0
ppc/spapr: fix drc index mismatch for partially enabled vcpus
ppc/pnv: Add xscom- prefix to pervasive-control region name
target/ppc: Fix THREAD_SIBLING_FOREACH for multi-socket
ppc/pnv: Fix direct controls quiesce
target/ppc: Fix non-maskable interrupt while halted
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* tag 'pull-target-arm-20241126' of https://git.linaro.org/people/pmaydell/qemu-arm:
docs/system/arm/aspeed: add missing model supermicrox11spi-bmc
docs/system/arm/fby35: update link to product page
docs/system/arm/: add FEAT_DoubleLock
docs/system/arm/: add FEAT_MTE_ASYNC
target/arm/tcg/: fix typo in FEAT name
docs/system/arm/emulation: add FEAT_SSBS2
docs/system/arm/emulation: fix typo in feature name
docs/system/arm/emulation: mention armv9
target/arm/tcg/cpu32.c: swap ATCM and BTCM register names
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
BALATON Zoltan [Mon, 25 Nov 2024 05:48:45 +0000 (15:48 +1000)]
hw/ppc/pegasos2: Fix IRQ routing from pci.0
The MV64361 has two PCI buses one of which is used for AGP on
PegasosII. So far we only emulated the PCI bus on pci.1 but some
graphics cards are only recognised by some guests when connected to
pci.0 corresponding to the AGP port. So far the interrupts were not
routed from pci.0 so this patch fixes that allowing the use of both
PCI buses. On real board only INTA and INTB are connected for AGP but
to avoid surprises we connect all 4 PCI interrupt lines so pci.0 can
be used for all PCI cards as well.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
ppc/spapr: fix drc index mismatch for partially enabled vcpus
In case when vcpus are explicitly enabled/disabled in a non-consecutive
order within a libvirt xml, it results in a drc index mismatch during
vcpu hotplug later because the existing logic uses vcpu id to derive the
corresponding drc index which is not correct. Use env->core_index to
derive a vcpu's drc index as appropriate to fix this issue.
For ex, for the given libvirt xml config:
<vcpus>
<vcpu id='0' enabled='yes' hotpluggable='no'/>
<vcpu id='1' enabled='yes' hotpluggable='yes'/>
<vcpu id='2' enabled='no' hotpluggable='yes'/>
<vcpu id='3' enabled='yes' hotpluggable='yes'/>
<vcpu id='4' enabled='no' hotpluggable='yes'/>
<vcpu id='5' enabled='yes' hotpluggable='yes'/>
<vcpu id='6' enabled='no' hotpluggable='yes'/>
<vcpu id='7' enabled='no' hotpluggable='yes'/>
</vcpus>
We see below error on guest console with "virsh setvcpus <domain> 5" :
pseries-hotplug-cpu: CPU with drc index 10000002 already exists
This patch fixes the issue by using correct drc index for explicitly
enabled vcpus during init.
Reported-by: Anushree Mathur <anushree.mathur@linux.vnet.ibm.com> Tested-by: Anushree Mathur <anushree.mathur@linux.vnet.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Glenn Miles [Thu, 14 Nov 2024 21:21:19 +0000 (15:21 -0600)]
target/ppc: Fix THREAD_SIBLING_FOREACH for multi-socket
The THREAD_SIBLING_FOREACH macro wasn't excluding threads from other
chips. Add chip_index field to the thread state and add a check for the
new field in the macro.
Fixes: b769d4c8f4c6 ("target/ppc: Add initial flags and helpers for SMT support") Signed-off-by: Glenn Miles <milesg@linux.ibm.com>
[npiggin: set chip_index for spapr too] Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Nicholas Piggin [Mon, 11 Nov 2024 05:23:29 +0000 (15:23 +1000)]
ppc/pnv: Fix direct controls quiesce
powernv CPUs have a set of control registers that can stop, start, and
do other things to control a thread's execution.
Using this interface to stop a thread puts it into a particular state
that can be queried, and is distinguishable from other things that might
stop the CPU (e.g., going idle, or being debugged via gdb, or stopped by
the monitor).
Add a new flag that can speficially distinguish this state where it is
stopped with control registers. This solves some hangs when rebooting
powernv machines when skiboot is modified to allow QEMU to use the CPU
control facility (that uses controls to bring all secondaries to a known
state).
Fixes: c8891955086 ("ppc/pnv: Implement POWER10 PC xscom registers for direct controls") Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Nicholas Piggin [Mon, 11 Nov 2024 06:37:49 +0000 (16:37 +1000)]
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 <milesg@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Pierrick Bouvier [Fri, 22 Nov 2024 22:50:43 +0000 (14:50 -0800)]
docs/system/arm/: add FEAT_DoubleLock
We already implement FEAT_DoubleLock (see commit f94a6df5dd6a7) when
the ID registers call for it. This feature is actually one that must
*not* be implemented in v9.0, but since our documentation lists
everything we can emulate, we should include FEAT_DoubleLock in the
list.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20241122225049.1617774-7-pierrick.bouvier@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: expand commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Michael Tokarev [Tue, 26 Nov 2024 16:12:09 +0000 (16:12 +0000)]
target/arm/tcg/cpu32.c: swap ATCM and BTCM register names
According to Cortex-R5 r1p2 manual, register with opcode2=0 is
BTCM and with opcode2=1 is ATCM, - exactly the opposite from how
qemu labels them. Just swap the labels to avoid confusion, -
both registers are implemented as always-zero.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241121171602.3273252-1-mjt@tls.msk.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 26 Nov 2024 14:06:39 +0000 (14:06 +0000)]
Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into staging
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCAAdFiEEIV1G9IJGaJ7HfzVi7wSWWzmNYhEFAmdFRyQACgkQ7wSWWzmN
# YhFU1Qf/T9bBOCrbQqbZSG7eKk8QuH35zcgNU7FzFTrGeVCc1bUMNYhiioqAFmE+
# h5h/3vmkmt+01vaTuimTRumI2SJnFFwggveJDWf+ICSl9MRtCXB5+w0n71vJ6gUO
# njm36pIl+aMkZIrsDc7lLewVouZkF8mAKP7mn9x53s5lX/HbXZSdPJmrkdUXtNT5
# d3nXlUkNhEWKL9dKIQ9dWYmj3l+tLfuYPiR8a+kKFMEwHlGBuFbNoVN03v5VvFyf
# Dmy1P1ZFApP0SsR4SiccXg7C8AslBC6wc7Bhd0aiKpGBnlt20mE9EJSVyrU8yP1p
# UTKzzB0QHN7Nnd6AcFRhWvo9C74mGg==
# =qP+q
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 26 Nov 2024 03:57:24 GMT
# gpg: using RSA key 215D46F48246689EC77F3562EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* tag 'net-pull-request' of https://github.com/jasowang/qemu:
virtio-net: Add queues before loading them
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
projects / thirdparty / qemu.git / log
