| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
|
|
Peter points out double underscore prefix names tend to be reserved
for the system. Clean these up.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
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-3-npiggin@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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:
commit 0d2eeef77a33315187df8519491a900bde4a3d83
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: 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 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>
|
|
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: 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>
|
|
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>
|
|
The PCI Interrupt Pin Register does not apply to VFs and MUST be
hardwired to zero.
Fixes: 44c2c09488db ("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 fa905f65c554 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.
Cc: qemu-stable@nongnu.org
Fixes: fa905f65c554 ("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>
|
|
Multifd receive threads run on the destination side.
Correct the thread name marco to indicate the same.
Fixes: e620b1e4770b ("migration: Put thread names together with macros")
Signed-off-by: Prasad Pandit <pjp@fedoraproject.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20241127111528.167330-1-ppandit@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
This patch simplifies (and makes less confusing) bit checks by
replacing `find_next_bit()` calls with boolean AND operation.
Resolves: Coverity CID 1563776
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com>
Cc: qemu-devel@nongnu.org
Message-ID: <20241129103239.464061-3-r.peniaev@gmail.com>
|
|
Allthough the size of MAX_MUX is equal to 4 and likely will never
change, this patch changes type of constant to unsigned long to
be on the safe side.
Also add a static compile check that MAX_MUX never bigger than
`sizeof(d->mux_bitset) * BITS_PER_BYTE`.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Clément Mathieu--Drif <clement.mathieu--drif@eviden.com>
Cc: qemu-devel@nongnu.org
Message-ID: <20241129103239.464061-2-r.peniaev@gmail.com>
|
|
This verifies expected behaviour of previous bug fix patch.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <7017658155c517b9665b75333a97c79aa2d4f3df.1732465720.git.qemu_oss@crudebyte.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: 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>
|
|
All 9p response types are prefixed with an "R", therefore fix
"READDIR" -> "RREADDIR" in function rmessage_name().
Fixes: 4829469fd9ff ("tests/virtio-9p: added readdir test")
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <daad7af58b403aaa2487c566032beca36664b30e.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.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_oss@crudebyte.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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:
https://gitlab.com/qemu-project/qemu/-/issues/2694
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>
|
|
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>
|
|
hvf on Arm is supported since commit a1477da3ddeb ("hvf: Add Apple
Silicon support").
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Alexander Graf <agraf@csgraf.de>
Message-ID: <20241127-build-v1-1-65b8162733f0@daynix.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
|
|
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>
|
|
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>
|
|
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.
[000h 0000 004h] Signature : "SRAT" [System Resource Affinity Table]
...
[030h 0048 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
...
[032h 0050 001h] Proximity Domain Low(8) : 00
[033h 0051 001h] Apic ID : 00
...
[040h 0064 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
...
[042h 0066 001h] Proximity Domain Low(8) : 03
[043h 0067 001h] Apic ID : 01
...
[050h 0080 001h] Subtable Type : 00 [Processor Local APIC/SAPIC Affinity]
...
[052h 0082 001h] Proximity Domain Low(8) : 05
[053h 0083 001h] Apic ID : 02
...
[060h 0096 001h] Subtable Type : 01 [Memory Affinity]
...
[062h 0098 004h] Proximity Domain : 00000000
...
[068h 0104 008h] Base Address : 0000000000000000
[070h 0112 008h] Address Length : 00000000000A0000
...
[088h 0136 001h] Subtable Type : 01 [Memory Affinity]
...
[08Ah 0138 004h] Proximity Domain : 00000000
...
[090h 0144 008h] Base Address : 0000000000100000
[098h 0152 008h] Address Length : 0000000003F00000
...
[0B0h 0176 001h] Subtable Type : 01 [Memory Affinity]
...
[0B2h 0178 004h] Proximity Domain : 00000004
...
[0B8h 0184 008h] Base Address : 0000000004000000
[0C0h 0192 008h] Address Length : 0000000004000000
... some zero length entries follow...
[1A0h 0416 001h] Subtable Type : 05 [Generic Initiator Affinity]
[1A1h 0417 001h] Length : 20
[1A2h 0418 001h] Reserved1 : 00
[1A3h 0419 001h] Device Handle Type : 01
[1A4h 0420 004h] Proximity Domain : 00000001
[1A8h 0424 010h] Device Handle : 00 00 01 02 00 00 00 00 00 00 00 00 00 00 00 00
[1B8h 0440 004h] Flags (decoded below) : 00000001
Enabled : 1
Architectural Transactions : 0
[1BCh 0444 004h] Reserved2 : 00000000
[1C0h 0448 001h] Subtable Type : 06 [Generic Port Affinity]
[1C1h 0449 001h] Length : 20
[1C2h 0450 001h] Reserved1 : 00
[1C3h 0451 001h] Device Handle Type : 00
[1C4h 0452 004h] Proximity Domain : 00000002
[1C8h 0456 010h] Device Handle : 41 43 50 49 30 30 31 36 40 00 00 00 00 00 00 00
[1D8h 0472 004h] Flags (decoded below) : 00000001
Enabled : 1
Architectural Transactions : 0
[1DCh 0476 004h] Reserved2 : 00000000
[1E0h 0480 001h] Subtable Type : 01 [Memory Affinity]
...
[1E2h 0482 004h] Proximity Domain : 00000005
...
[1E8h 0488 008h] Base Address : 0000000100000000
[1F0h 0496 008h] Address Length : 0000000090000000
Example block from HMAT:
[0F0h 0240 002h] Structure Type : 0001 [System Locality Latency and Bandwidth Information]
[0F2h 0242 002h] Reserved : 0000
[0F4h 0244 004h] Length : 00000078
[0F8h 0248 001h] Flags (decoded below) : 00
Memory Hierarchy : 0
Use Minimum Transfer Size : 0
Non-sequential Transfers : 0
[0F9h 0249 001h] Data Type : 03
[0FAh 0250 001h] Minimum Transfer Size : 00
[0FBh 0251 001h] Reserved1 : 00
[0FCh 0252 004h] Initiator Proximity Domains # : 00000004
[100h 0256 004h] Target Proximity Domains # : 00000006
[104h 0260 004h] Reserved2 : 00000000
[108h 0264 008h] Entry Base Unit : 0000000000000004
[110h 0272 004h] Initiator Proximity Domain List : 00000000
[114h 0276 004h] Initiator Proximity Domain List : 00000001
[118h 0280 004h] Initiator Proximity Domain List : 00000003
[11Ch 0284 004h] Initiator Proximity Domain List : 00000005
[120h 0288 004h] Target Proximity Domain List : 00000000
[124h 0292 004h] Target Proximity Domain List : 00000001
[128h 0296 004h] Target Proximity Domain List : 00000002
[12Ch 0300 004h] Target Proximity Domain List : 00000003
[130h 0304 004h] Target Proximity Domain List : 00000004
[134h 0308 004h] Target Proximity Domain List : 00000005
[138h 0312 002h] Entry : 00C8
[13Ah 0314 002h] Entry : 0000
[13Ch 0316 002h] Entry : 0032
[13Eh 0318 002h] Entry : 0000
[140h 0320 002h] Entry : 0032
[142h 0322 002h] Entry : 0064
[144h 0324 002h] Entry : 0019
[146h 0326 002h] Entry : 0000
[148h 0328 002h] Entry : 0064
[14Ah 0330 002h] Entry : 0000
[14Ch 0332 002h] Entry : 00C8
[14Eh 0334 002h] Entry : 0019
[150h 0336 002h] Entry : 0064
[152h 0338 002h] Entry : 0000
[154h 0340 002h] Entry : 0032
[156h 0342 002h] Entry : 0000
[158h 0344 002h] Entry : 0032
[15Ah 0346 002h] Entry : 0064
[15Ch 0348 002h] Entry : 0064
[15Eh 0350 002h] Entry : 0000
[160h 0352 002h] Entry : 0032
[162h 0354 002h] Entry : 0000
[164h 0356 002h] Entry : 0032
[166h 0358 002h] Entry : 00C8
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>
|
|
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>
|
|
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>
|