KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
kvm_set_phys_mem: error registering slot: Invalid argument
Aborted (core dumped)
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>
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>
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>
If the binary loaded via -kernel is *not* a linux kernel (in which
case protocol == 0), do not patch the linux kernel header fields.
It's (a) pointless and (b) might break binaries by random patching
and (c) changes the binary hash which in turn breaks secure boot
verification.
Background: OVMF happily loads and runs not only linux kernels but
any efi binary via direct kernel boot.
Note: Breaking the secure boot verification is a problem for linux
kernels too, but fixed that is left for another day ...
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20240905141211.1253307-3-kraxel@redhat.com>
(cherry picked from commit 57e2cc9abf5da38f600354fe920ff20e719607b4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The released fix for this CVE:
f6b0de53fb ("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 f6b0de53fb 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: f6b0de53fb ("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>
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-----
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>
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:
commit 0d2eeef77a
Author: Bibo Mao <maobibo@loongson.cn>
Date: Mon Oct 28 10:38:09 2024 +0800
linux-headers: Update to Linux v6.12-rc5
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: 0d2eeef77a ("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>
The 'pci-vga' device allow setting a 'big-endian-framebuffer'
property since commit 3c2784fc86 ("vga: Expose framebuffer
byteorder as a QOM property"). Similarly, the 'virtio-vga'
device since commit 8be61ce2ce ("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>
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>
We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.
This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.
This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.
Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0. To fix
Linux we fix three things in the device tree:
1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.
In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:
* serial_hd(0) is the lowest-address UART
* serial_hd(0) is listed first in the DTB
* serial_hd(0) is the /chosen/stdout-path one
* the /aliases/serial0 alias points at serial_hd(0)
[1]: https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab32e2@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad
[stafford: Change to serial0 alias and update change message, reverse
uart registration order]
Fixes: 777784bda4 ("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>
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>
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>
We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.
This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.
This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.
Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0. To fix
Linux we fix three things in the device tree:
1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.
In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:
* serial_hd(0) is the lowest-address UART
* serial_hd(0) is listed first in the DTB
* serial_hd(0) is the /chosen/stdout-path one
* the /aliases/serial0 alias points at serial_hd(0)
[1]: https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab32e2@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad
Fixes: 777784bda4 ("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>
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 08f6328480
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad2512 ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee5d1, exposing the bug yet again.
Cc: qemu-stable@nongnu.org
Fixes: 08f6328480 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
The PCI Interrupt Pin Register does not apply to VFs and MUST be
hardwired to zero.
Fixes: 44c2c09488 ("hw/nvme: Add support for SR-IOV")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Only call msix_{un,}use_vector() when interrupts are actually enabled
for a completion queue.
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Commit fa905f65c5 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.
Cc: qemu-stable@nongnu.org
Fixes: fa905f65c5 ("hw/nvme: add machine compatibility parameter to enable msix exclusive bar")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.
I.e. this fixes the following misbehaviour with a 9p Linux client:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)
Expected results:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.
Fixes: 00ede4c252 ("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: e06a765efb ("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>
Drop V9fsFidState's 'next' member, which is no longer used since:
f5265c8f91 ('9pfs: use GHashTable for fid table')
Fixes: f5265c8f91 ('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>
Host drivers do not necessarily set cdb_len in megasas io commands.
With commits 6d1511cea0 ("scsi: Reject commands if the CDB length
exceeds buf_len") and fe9d8927e2 ("scsi: Add buf_len parameter to
scsi_req_new()"), this results in failures to boot Linux from affected
SCSI drives because cdb_len is set to 0 by the host driver.
Set the cdb length to its actual size to solve the problem.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.kernel.org/r/20230228171129.4094709-1-linux@roeck-us.net
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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: b12cb3819b (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>
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.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmdHJRIPHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRpTkQIAJYFpFTPRnO8mA6gurfheB7Jt0ywAMrjKWfg
uEkfZXXSQeCS8NBNPoZt7S8AE6xHE2a4b5lNWiS4a4coFmgTjtKPM8YsU01riyRk
EasRxynGua2XGUWGK93r9L27v9zGz/vRC0Lujmw3VAUKGeL7a17KzmxwXLXe+DzS
PgcI/H5hqoCDalT8aF6wOEDaWIHeo4dauDubYavW/+yaPtUvmy9MBkXbIV4iYqT5
V6geeYIKW/yE/GHxxXOw/RE1FgpiZhebtQP26jPTSk0z/JaV5S0DNYs07joXmbaU
fW5LSLgH3+oDI/GIhvsZ6hP87rVXBdaAogeJqT8SsuChBR55TpY=
=B7KB
-----END PGP SIGNATURE-----
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.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmdHJRIPHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpTkQIAJYFpFTPRnO8mA6gurfheB7Jt0ywAMrjKWfg
# uEkfZXXSQeCS8NBNPoZt7S8AE6xHE2a4b5lNWiS4a4coFmgTjtKPM8YsU01riyRk
# EasRxynGua2XGUWGK93r9L27v9zGz/vRC0Lujmw3VAUKGeL7a17KzmxwXLXe+DzS
# PgcI/H5hqoCDalT8aF6wOEDaWIHeo4dauDubYavW/+yaPtUvmy9MBkXbIV4iYqT5
# V6geeYIKW/yE/GHxxXOw/RE1FgpiZhebtQP26jPTSk0z/JaV5S0DNYs07joXmbaU
# fW5LSLgH3+oDI/GIhvsZ6hP87rVXBdaAogeJqT8SsuChBR55TpY=
# =B7KB
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 27 Nov 2024 13:56:34 GMT
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* 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>
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>
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>
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().
Resolves CID 1564900 and 1564901
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>
This reverts commit 2d6cfbaf17.
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>
This reverts commit bf1ecc8dad
which broke cpu hotplug in x86 after migration to older QEMU
Fixes: bf1ecc8dad (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>
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>
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>
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>
By convention, xscom regions get a xscom- prefix.
Fixes: 1adf24708b ("hw/ppc: Add pnv nest pervasive common chiplet model")
Reviewed-by: Glenn Miles <milesg@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
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: b769d4c8f4 ("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>
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: c889195508 ("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>
Matt Borgerson