We've got two versions of the QEMU logo in the repository, one with
the whole word "QEMU" (pc-bios/qemu_logo.svg) and one that only contains
the letter "Q" (ui/icons/qemu.svg). While qemu_logo.svg contains the
proper metadata with license and author information, this is missing
from the ui/icons/qemu.svg file. Copy the meta data there so that
people have a chance to know the license of the file if they only
look at the qemu.svg file.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/3139
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250930071419.117592-1-thuth@redhat.com>
(cherry picked from commit 9163424c50)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If the guest feeds invalid data to the UHCI controller, we
can assert:
qemu-system-x86_64: ../../hw/usb/core.c:744: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed.
(see issue 2548 for the repro case). This happens because the guest
attempts USB_TOKEN_SETUP to an endpoint other than 0, which is not
valid. The controller code doesn't catch this guest error, so
instead we hit the assertion in the USB core code.
Catch the case of SETUP to non-zero endpoint, and treat it as a fatal
error in the TD, in the same way we do for an invalid PID value in
the TD.
This is the UHCI equivalent of the same bug in OHCI that we fixed in
commit 3c3c233677 ("hw/usb/hcd-ohci: Fix#1510, #303: pid not IN or
OUT").
This bug has been tracked as CVE-2024-8354.
Cc: qemu-stable@nongnu.org
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2548
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit d0af3cd027)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit e13e1195db)
(Mjt: resolve context conflict in tests/tcg/multiarch/Makefile.target)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When we remove dest from orig's links, we lose the link
that we rely on later to reset links. This can lead to
failure to release from spinlock with self-modifying code.
Cc: qemu-stable@nongnu.org
Reported-by: 李威威 <liweiwei@kubuds.cn>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Tested-by: Anton Johansson <anjo@rev.ng>
(cherry picked from commit 03fe665980)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
While running the kvm-unit-tests on Intel platforms with "split lock
disable" feature, every test triggers a kernel warning of
x86/split lock detection: #AC: qemu-system-x86_64/373232 took a split_lock trap at address: 0x1e3
Hack KVM by exiting to QEMU on split lock #AC, we get
KVM: exception 17 exit (error code 0x0)
EAX=00000001 EBX=00000000 ECX=00000014 EDX=0001fb80
ESI=00000000 EDI=000000a8 EBP=00000000 ESP=00006f10
EIP=000001e3 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0900 00009000 0000ffff 00009300 DPL=0 DS16 [-WA]
CS =c000 000c0000 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
DS =c000 000c0000 0000ffff 00009300 DPL=0 DS16 [-WA]
FS =0950 00009500 0000ffff 00009300 DPL=0 DS16 [-WA]
GS =06f2 00006f20 0000ffff 00009300 DPL=0 DS16 [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 000c02b4 00000027
IDT= 00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=89 16 08 00 65 66 0f 01 16 06 00 66 b8 01 00 00 00 0f 22 c0 <65> 66 ff 2e 00 00 b8 10 00 00 00 8e d0 8e d8 8e c0 8e e0 8e e8 66 b8 08 00 66 ba 10 05 66
And it matches with what disassembled from multiboo_dma.bin:
#objdump -b binary -m i386 -D pc-bios/multiboot_dma.bin
1d1: 08 00 or %al,(%eax)
1d3: 65 66 0f 01 16 lgdtw %gs:(%esi)
1d8: 06 push %es
1d9: 00 66 b8 add %ah,-0x48(%esi)
1dc: 01 00 add %eax,(%eax)
1de: 00 00 add %al,(%eax)
1e0: 0f 22 c0 mov %eax,%cr0
> 1e3: 65 66 ff 2e ljmpw *%gs:(%esi)
1e7: 00 00 add %al,(%eax)
1e9: b8 10 00 00 00 mov $0x10,%eax
1ee: 8e d0 mov %eax,%ss
1f0: 8e d8 mov %eax,%ds
1f2: 8e c0 mov %eax,%es
1f4: 8e e0 mov %eax,%fs
1f6: 8e e8 mov %eax,%gs
1f8: 66 b8 08 00 mov $0x8,%ax
1fc: 66 ba 10 05 mov $0x510,%dx
We can see that the instruction at 0x1e3 is a far jmp through the GDT.
However, the GDT is not 8 byte aligned, the base is 0xc02b4.
Intel processors follow the LOCK semantics to set the accessed flag of the
segment descriptor when loading a segment descriptor. If the the segment
descriptor crosses two cache line, it causes split lock.
Fix it by aligning the GDT on 8 bytes, so that segment descriptor cannot
span two cache lines.
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/20250808035027.2194673-1-xiaoyao.li@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4c8f69b948)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When no monitor address is given, establish the QMP communication through
a socketpair() (API is also supported on Windows since Python 3.5)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20230111080101.969151-4-marcandre.lureau@redhat.com
[Resolved conflicts, fixed typing error. --js]
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit bd4c0ef409)
(Mjt: this fixes quite a few qemu iotests which was probably racing somewhere)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
On macOS, private $TMPDIR's are the default. These $TMPDIR's are
generated from a user's unix UID and UUID [1], which can create a
relatively long path:
/var/folders/d7/rz20f6hd709c1ty8f6_6y_z40000gn/T/
QEMU's avocado tests create a temporary directory prefixed by
"avo_qemu_sock_", and create QMP sockets within _that_ as well.
The QMP socket is unnecessarily long, because a temporary directory
is created for every QEMUMachine object.
/avo_qemu_sock_uh3w_dgc/qemu-37331-10bacf110-monitor.sock
The path limit for unix sockets on macOS is 104: [2]
/*
* [XSI] Definitions for UNIX IPC domain.
*/
struct sockaddr_un {
unsigned char sun_len; /* sockaddr len including null */
sa_family_t sun_family; /* [XSI] AF_UNIX */
char sun_path[104]; /* [XSI] path name (gag) */
};
This results in avocado tests failing on macOS because the QMP unix
socket can't be created, because the path is too long:
ERROR| Failed to establish connection: OSError: AF_UNIX path too long
This change resolves by reducing the size of the socket directory prefix
and the suffix on the QMP and console socket names.
The result is paths like this:
pdel@pdel-mbp:/var/folders/d7/rz20f6hd709c1ty8f6_6y_z40000gn/T
$ tree qemu*
qemu_df4evjeq
qemu_jbxel3gy
qemu_ml9s_gg7
qemu_oc7h7f3u
qemu_oqb1yf97
├── 10a004050.con
└── 10a004050.qmp
[1] https://apple.stackexchange.com/questions/353832/why-is-mac-osx-temp-directory-in-weird-path
[2] /Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/sys/un.h
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230110082930.42129-2-peter@pjd.dev
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit f9922937d1)
(Mjt: pick this simple fix for 7.2.x so subsequent changes applies cleanly)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
More recent fedora does not have our minimum python versions
anymore. Stick with the most common fedora version used in
7.2.x in other places, which is 37. This way, python tests
works again.
This is a 7.2-specific change, not aimed for the master branch.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
USB NICs have a "40:" prefix hardcoded for all MAC addresses when we
return the guest the MAC address if it queries the STRING_ETHADDR USB
string property. This doesn't match what we use for the
OID_802_3_PERMANENT_ADDRESS or OID_802_3_CURRENT_ADDRESS OIDs for
NDIS, or the MAC address we actually use in the QEMU networking code
to send/receive packets for this device, or the NIC info string we
print for users. In all those other places we directly use
s->conf.macaddr.a, which is the full thing the user asks for.
This overrides user-provided configuration and leads to an inconsistent
experience.
I couldn't find any documented reason (comment or git commits) for
this behavior. It seems like everyone is just expecting the MAC
address to be fully passed through to the guest, but it isn't.
This may have been a debugging hack that accidentally made it through
to the accepted patch: it has been in the code since it was originally
added back in 2008.
This is also particularly problematic as the "40:" prefix isn't a
reserved prefix for MAC addresses (IEEE OUI). There are a number of
valid allocations out there which use this prefix, meaning that QEMU
may be causing MAC address conflicts.
Cc: qemu-stable@nongnu.org
Fixes: 6c9f886cea ("Add CDC-Ethernet usb NIC (original patch from Thomas Sailer)"
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2951
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[PMM: beef up commit message based on mailing list discussion]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit aaf042299a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The tests are built once for all the targets, so as long as one QEMU
binary is built with CONFIG_LSI_SCSI_PCI=y, this test will
run. However some binaries might not include the device. So check this
again in runtime.
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-Id: <20230208194700.11035-3-farosas@suse.de>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit dee66bc969)
(Mjt: pick this trivial focused fix up for 7.2.x so that subsequent change(s) in this area apply cleanly)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the scenario where vhost-user sets eventfd to -1,
qemu_chr_fe_get_msgfds retrieves fd as -1. When vhost_user_read
receives, it does not perform blocking operations on the descriptor
with fd=-1, so non-blocking operations should not be performed here
either.This is a normal use case. Calling g_unix_set_fd_nonblocking
at this point will cause the test to interrupt.
When vhost_user_write sets the call fd to -1, it sets the number of
fds to 0, so the fds obtained by qemu_chr_fe_get_msgfds will also
be 0.
Signed-off-by: Yuxue Liu <yuxue.liu@jaguarmicro.com>
Message-Id: <20240411073555.1357-1-yuxue.liu@jaguarmicro.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit f72fc16910)
(Mjt: pick this trivial focused change up for 7.2.x so that subsequent change(s) in this area apply cleanly)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
chr_read() is printing an error message and returning with s->data_mutex taken.
This can potentially cause a hang. Reported by Coverity.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20230427125423.103536-1-pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 3ee7f21ed2)
(Mjt: pick this trivial focused change up for 7.2.x so that subsequent fixes in this area applies cleanly)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
block/curl.c uses CURLMOPT_SOCKETFUNCTION to register a socket callback.
According to the documentation, this callback is called not just with
application-created sockets but also with internal curl sockets, - and
for such sockets, user data pointer is not set by the application, so
the result qemu crashing.
Pass BDRVCURLState directly to the callback function as user pointer,
instead of relying on CURLINFO_PRIVATE.
This problem started happening with update of libcurl from 8.9 to 8.10 --
apparently with this change curl started using private handles more.
(CURLINFO_PRIVATE is used in one more place, in curl_multi_check_completion() -
it might need a similar fix too)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3081
Cc: qemu-stable@qemu.org
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 606978500c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Use extract64(entry, psn, 1) instead of (entry & (1 << psn)) to avoid
undefined behavior for shifts by 32–63 and to make bit extraction intent explicit.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Rastyogin <gerben@altlinux.org>
Message-ID: <20250814104914.13101-1-gerben@altlinux.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1f82ca7234)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Per the release 6.06 revision history:
5.03 August 21, 2013
• ABS2008 and NAN2008 fields of Table 5.7 “FCSR RegisterField
Descriptions” were optional in release 3 and could be R/W,
but as of release 5 are required, read-only, and preset by
hardware.
The P5600 core implements the release 5, and has the ABS2008
and NAN2008 bits set in CP1_fcr31. Therefore it is able to run
ELF binaries compiled with EF_MIPS_NAN2008, such the CIP United
Debian NaN2008 distribution:
http://repo.oss.cipunited.com/mipsel-nan2008/README.txt
In order to run such compiled binaries, select by default the
P5600 core when the ELF 'MIPS_NAN2008' flag is set.
Reported-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Acked-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20230327162444.388-1-philmd@linaro.org>
(cherry picked from commit 450cb7ec2c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
A race condition between guest driver actions and QEMU timers can lead
to an assertion failure when the guest switches the e1000e from legacy
interrupt mode to MSI-X. If a legacy interrupt delay timer (TIDV or
RDTR) is active, but the guest enables MSI-X before the timer fires,
the pending interrupt cause can trigger an assert in
e1000e_intmgr_collect_delayed_causes().
This patch removes the assertion and executes the code that clears the
pending legacy causes. This change is safe and introduces no unintended
behavioral side effects, as it only alters a state that previously led
to termination.
- when core->delayed_causes == 0 the function was already a no-op and
remains so.
- when core->delayed_causes != 0 the function would previously
crash due to the assertion failure. The patch now defines a safe
outcome by clearing the cause and returning. Since behavior after
the assertion never existed, this simply corrects the crash.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1863
Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250807110806.409065-1-lvivier@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 8e4649cac9)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
If capture-output is requested but one of the channels goes unused (eg.
we attempt to capture stderr but the command never writes to stderr), we
can leak memory.
guest_exec_output_watch() is (from what I understand) unconditionally
called for both streams if output capture is requested. The first call
will always pass the `p->size == p->length` check b/c both values are
0. Then GUEST_EXEC_IO_SIZE bytes will be allocated for the stream.
But when we reap the exited process there's a `gei->err.length > 0`
check to actually free the buffer. Which does not get run if the command
doesn't write to the stream.
Fix by making free() unconditional.
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
(cherry picked from commit d6f67b83b8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we call object_new() and then later qdev_realize(),
and we never unref the object on deinit. This causes a leak,
detected by ASAN on the device-introspect-test:
Indirect leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe)
#1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18
#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12
#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10
#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12
#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9
#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5
#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5
#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9
#12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5
#13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5
#14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26
Switch to using object_initialize_child() like all our
other child objects for this SoC object.
Cc: qemu-stable@nongnu.org
Fixes: b63041c8f6 ("STM32F205: Connect the ADC devices")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org
(cherry picked from commit 2e27650bdd)
(Mjt: adjust for 7.2, for before qemu_or_irq rename to OrIRQState)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Newer versions of Perl (5.41.x and up) emit a warning for code in
kernel-doc:
Possible precedence problem between ! and pattern match (m//) at /scripts/kernel-doc line 1597.
This is because the code does:
if (!$param =~ /\w\.\.\.$/) {
In Perl, the ! operator has higher precedence than the =~
pattern-match binding, so the effect of this condition is to first
logically-negate the string $param into a true-or-false value and
then try to pattern match it against the regex, which in this case
will always fail. This is almost certainly not what the author
intended.
In the new Python version of kernel-doc in the Linux kernel,
the equivalent code is written:
if KernRe(r'\w\.\.\.$').search(param):
# For named variable parameters of the form `x...`,
# remove the dots
param = param[:-3]
else:
# Handles unnamed variable parameters
param = "..."
which is a more sensible way of writing the behaviour you would
get if you put in brackets to make the regex match first and
then negate the result.
Take this as the intended behaviour, and update the Perl to match.
For QEMU, this produces no change in output, presumably because we
never used the "unnamed variable parameters" syntax.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Message-id: 20250819115648.2125709-1-peter.maydell@linaro.org
(cherry picked from commit 5ffd387e9e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
virtio_net_pre_load_queues() inspects vdev->guest_features to tell if
VIRTIO_NET_F_RSS or VIRTIO_NET_F_MQ is enabled to infer the required
number of queues. This works for VIRTIO_NET_F_MQ but it doesn't for
VIRTIO_NET_F_RSS because only the lowest 32 bits of vdev->guest_features
is set at the point and VIRTIO_NET_F_RSS uses bit 60 while
VIRTIO_NET_F_MQ uses bit 22.
Instead of inferring the required number of queues from
vdev->guest_features, use the number loaded from the vm state. This
change also has a nice side effect to remove a duplicate peer queue
pair change by circumventing virtio_net_set_multiqueue().
Also update the comment in include/hw/virtio/virtio.h to prevent an
implementation of pre_load_queues() from refering to any fields being
loaded during migration by accident in the future.
Fixes: 8c49756825 ("virtio-net: Add only one queue pair when realizing")
Fixes: 653217a501 ("virtio-net: Add only one queue pair when realizing" in 7.2.x)
Tested-by: Lei Yang <leiyang@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit adda0ad56b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Call virtio_net_set_multiqueue() to add queues before loading their
states. Otherwise the loaded queues will not have handlers and elements
in them will not be processed.
Cc: qemu-stable@nongnu.org
Fixes: 8c49756825 ("virtio-net: Add only one queue pair when realizing")
Fixes: 653217a501 ("virtio-net: Add only one queue pair when realizing" in 7.2.x)
Reported-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 9379ea9db3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Multiqueue usage is not negotiated yet when realizing. If more than
one queue is added and the guest never requests to enable multiqueue,
the extra queues will not be deleted when unrealizing and leak.
Fixes: f9d6dbf0bf ("virtio-net: remove virtio queues if the guest doesn't support multiqueue")
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 8c49756825)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For all 32-bit systems and 64-bit Windows systems, "long" is 4 bytes long.
Due to using "long" for a linear address, svm_canonicalization would
set all high bits to 1 when (assuming 48-bit linear address) the segment
base is bigger than 0x7FFF.
This fixes booting guests under TCG when the guest IDT and GDT bases are
above 0x7FFF, thereby resulting in incorrect bases. When an interrupt
arrives, it would trigger a #PF exception; the #PF would trigger again,
resulting in a #DF exception; the #PF would trigger for the third time,
resulting in triple-fault, and eventually causes a shutdown VM-Exit to
the hypervisor right after guest boot.
Cc: qemu-stable@nongnu.org
Signed-off-by: Zero Tang <zero.tangptr@gmail.com>
(cherry picked from commit c12cbaa007)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit 1585ab9f1b ("hw/sd/sdcard: Fill SPI response bits in card
code") exposed a bug in the SPI adapter: if no SD card is plugged,
we are returning "there is a card with an error". This is wrong,
we shouldn't return any particular packet response, but the noise
shifted on the MISO line. Return the dummy byte, otherwise we get:
qemu-system-riscv64: ../hw/sd/ssi-sd.c:160: ssi_sd_transfer: Assertion `s->arglen > 0' failed.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 775616c3ae ("Partial SD card SPI mode support")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250812140415.70153-2-philmd@linaro.org>
(cherry picked from commit e262646e12)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
On AST1030, reading the FMC_WDT2 register always returns 0xFFFFFFFF.
This issue is due to the aspeed_smc_read function, which checks for the
ASPEED_SMC_FEATURE_WDT_CONTROL feature. Since AST1030 was missing this
feature flag, the read operation fails and returns -1.
To resolve this, add the WDT_CONTROL feature to AST1030's feature set
so that FMC_WDT2 can be correctly accessed by firmware.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Fixes: 2850df6a81 ("aspeed/smc: Add AST1030 support ")
Link: https://lore.kernel.org/qemu-devel/20250804014633.512737-1-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 13ed972b4c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The code to handle setting SVE registers via the gdbstub is broken:
* it sets each pair of elements in the zregs[].d[] array in the
wrong order for the most common (little endian) case: the least
significant 64-bit value comes first
* it makes no attempt to handle target_endian()
* it does a simple copy out of the (target endian) gdbstub buffer
into the (host endan) zregs data structure, which is wrong on
big endian hosts
Fix all these problems:
* use ldq_p() to read from the gdbstub buffer
* check target_big_endian() to see if we need to handle the
128-bit values the opposite way around
Cc: qemu-stable@nongnu.org
Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com>
Message-id: 20250722173736.2332529-3-vacha.bhavsar@oss.qualcomm.com
[PMM: adjusted commit message, fixed spacing]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 97b3d732af)
(Mjt: s/target_big_endian/target_words_bigendian/ due to missing
v10.0.0-277-gb939b8e42a "exec: Rename target_words_bigendian() -> target_big_endian()")
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In the code for allowing the gdbstub to set the value of an AArch64
FP/SIMD register, we weren't accounting for target_big_endian()
being true. This meant that for aarch64_be-linux-user we would
set the two halves of the FP register the wrong way around.
The much more common case of a little-endian guest is not affected;
nor are big-endian hosts.
Correct the handling of this case.
Cc: qemu-stable@nongnu.org
Signed-off-by: Vacha Bhavsar <vacha.bhavsar@oss.qualcomm.com>
Message-id: 20250722173736.2332529-2-vacha.bhavsar@oss.qualcomm.com
[PMM: added comment, expanded commit message, fixed missing space]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 35cca0f95f)
(Mjt: s/target_big_endian/target_words_bigendian/ due to missing
v10.0.0-277-gb939b8e42a "exec: Rename target_words_bigendian() -> target_big_endian()")
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
KVM's userspace access interface to the GICD enable and active bits
is via set/clear register pairs which implement the hardware's "write
1s to the clear register to clear the 0 bits, and write 1s to the set
register to set the 1 bits" semantics. We didn't get this right,
because we were writing 0 to the clear register.
Writing 0 to GICD_IC{ENABLE,ACTIVE}R architecturally has no effect on
interrupt status (all writes are simply ignored by KVM) and doesn't
comply with the intention of "first write to the clear-reg to clear
all bits".
Write all 1's to actually clear the enable/active status.
This didn't have any adverse effects on migration because there
we start with a clean VM state; it would be guest-visible when
doing a system reset, but since Linux always cleans up the
register state of the GIC during bootup before it enables it
most users won't have run into a problem here.
Cc: qemu-stable@nongnu.org
Fixes: 367b9f527b ("hw/intc/arm_gicv3_kvm: Implement get/put functions")
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Message-id: 20250729161650.43758-3-zenghui.yu@linux.dev
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b10bd4bd17)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
According to the 'MIPS MT Application-Specific Extension' manual:
If the VPE executing the instruction is not a Master VPE,
with the MVP bit of the VPEConf0 register set, the EVP bit
is unchanged by the instruction.
Modify the DVPE/EVPE opcodes to only update the MVPControl.EVP bit
if executed on a master VPE.
Cc: qemu-stable@nongnu.org
Reported-by: Hansni Bu
Buglink: https://bugs.launchpad.net/qemu/+bug/1926277
Fixes: f249412c74 ("mips: Add MT halting and waking of VPEs")
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Message-ID: <20210427133343.159718-1-f4bug@amsat.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit e895095c78)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Table A-5 of the Intel manual incorrectly lists the third operand of
VINSERTx128 as Wqq, but it is actually a 128-bit value. This is
visible when W is a memory operand close to the end of the page.
Fixes the recently-added poly1305_kunit test in linux-next.
(No testcase yet, but I plan to modify test-avx2 to use memory
close to the end of the page. This would work because the test
vectors correctly have the memory operand as xmm2/m128).
Reported-by: Eric Biggers <ebiggers@kernel.org>
Tested-by: Eric Biggers <ebiggers@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: qemu-stable@nongnu.org
Fixes: 7906847768 ("target/i386: reimplement 0x0f 0x3a, add AVX", 2022-10-18)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit feea87cd6b)
(Mjt: adjust for 7.2.x due to lack of v8.1.0-2167-ge000687f12
"target/i386: validate VEX.W for AVX instructions")
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In case of multiple chunks, code in qxl_unpack_chunks() takes size of the
wrong (next in the chain) chunk, instead of using current chunk size.
This leads to wrong number of bytes being copied, and to crashes if next
chunk size is larger than the current one.
Based on the code by Gao Yong.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1628
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit b8882becd5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2025-07-29 20:15:11 +03:00
54 changed files with 425 additions and 198 deletions
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.