Rewrite reading of mouse pointer image. I am not sure this is entirely
correct but appears to work at least on little endian host with PPC
guests using little or big endian frame buffer (MorphOS and MacOS) but
still produces broken pointer image with Linux where I am not sure if
it is a guest driver bug or still missing something.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-ID: <b9de530074b954d661a0eb9b8b4ad82a66085456.1774110169.git.balaton@eik.bme.hu>
[PMD: Replaced BIT() -> BIT_ULL() in ati_cursor_draw_line()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
With the linear aperture size fixed to match real card fuloong2e no
longer works due to running out of PCI memory because only one PCI bus
is emulated on that machine. Add a property to allow fuloong2e to set
a smaller linear aperture size to work around that problem until the
machine model is improved.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Chad Jablonski <chad@jablonski.xyz>
Message-ID: <47cbdc7ad2291f22467f9fc86e7287eb8983c927.1774110169.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Coverity reports several possible sign extension errors (latest is CID
1645615). These cannot happen because the values are limited when
writing the registers and only 32 bits of the return value matter but
change type of the variable storing the return value to uint32_t to
avoid these warnings. Also change DEFAULT_SC_BOTTOM_RIGHT register
read to match what other similar registers do for consistency.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <9a3263a06bc72aa5a56bafe0a11ad189d5f60528.1774110169.git.balaton@eik.bme.hu>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
When a guest sets MaxPacketSize to 0 in an OHCI Endpoint Descriptor,
ohci_service_td() transfers 0 bytes per iteration. The Transfer
Descriptor never completes because CBP never advances toward BE,
causing ohci_service_ed_list() to loop indefinitely and hang QEMU.
Add a check for MPS==0 after extracting the field from ED flags.
If MPS is zero, call ohci_die() to reset the controller and return
an error, preventing the infinite loop.
Fixes: CVE-2026-3890
Reported-by: Jenny Guanni Qu <qguanni@gmail.com>
Signed-off-by: Jenny Guanni Qu <qguanni@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20260321000444.909451-1-qguanni@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
hyperv_is_synic_enabled() is a global flag that returns true after the
first CPU initializes SynIC. With -smp N, all subsequent CPUs skip
hyperv_x86_synic_add(), leaving them without a synic object. This causes
get_synic() to return NULL, making hyperv_sint_route_new() fail and
triggering an assertion crash in hyperv_testdev.
Fix by introducing hyperv_is_synic_present() which checks per-CPU
whether a synic object is already attached instead of using the global
flag.
Fixes: c4cf32fc63 ("kvm/hyperv: add synic feature to CPU only if its not enabled")
Reported-by: Xudong Hao <xudong.hao@intel.com>
Co-authored-by: Ani Sinha <anisinha@redhat.com>
Signed-off-by: Sourav Poddar <souravpoddar93042@gmail.com>
Tested-by: Xudong Hao <xudong.hao@intel.com>
Message-ID: <20260320154752.204725-1-anisinha@redhat.com>
[PMD: Reworded subject]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In case current kernel does not support /dev/iommu, qemu will probably
fail first because /sys/bus/pci/devices/*/vfio-dev/ is not present,
since QEMU opens it before /dev/iommu.
Instead, report an error directly when completing an iommufd object, to
inform user that kernel does not support it, with a hint about missing
CONFIG_IOMMUFD. We can't do this from initialize as there is no way to
return an error, and we don't want to abort at this step.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Message-ID: <20260319205942.367705-2-pierrick.bouvier@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Per CXL 4.0 Table 8-331, the Discovery operation "returns a list of
all Media Operations that the device supports, with the exception of
the Discovery operation (Class=0, Subclass=0)."
Filter out Discovery entries when building the output list and adjust
total_supported_operations accordingly.
Fixes: 77a8e9fe0e ("hw/cxl/cxl-mailbox-utils: Add support for Media operations discovery commands cxl r3.2 (8.2.10.9.5.3)")
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Message-ID: <20260319184256.3762391-3-dave@stgolabs.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The Discovery rejects requests where start_index + num_ops
exceeds the total number of supported operations. Per CXL 4.0
Table 8-332, num_ops is the "Maximum number of Media Operation to
return" - a maximum, not an exact count. The device should return
up to that many entries, not reject the request.
Cap num_ops to the available entries from start_index instead of
erroring the command.
Fixes: 77a8e9fe0e ("hw/cxl/cxl-mailbox-utils: Add support for Media operations discovery commands cxl r3.2 (8.2.10.9.5.3)")
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Message-ID: <20260319184256.3762391-2-dave@stgolabs.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Add a new call hyperv_enable_synic() that can be called whether or not
CONFIG_HYPERV is enabled. This way genetic code in i396/kvm.c can call this
function to enable synic for hyperv. For non-hyperv cases, the stub will
be a noop.
Reported-by: Michale Tokarev <mjt@tls.msk.ru>
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20260319122137.142178-3-anisinha@redhat.com>
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Coverity reports that dw_i3c_short_transfer() may pass an
uninitialized buffer to dw_i3c_send().
The immediate cause is the use of `data[len] += arg.byte0`, which
reads from an uninitialized element of the buffer. Replace this with
a simple assignment.
Additionally, avoid calling dw_i3c_send() when the constructed payload
length is zero. In that case the transfer has no data phase, so the
controller can transition to the idle state directly.
This resolves the Coverity UNINIT warning and clarifies the handling
of zero-length short transfers.
Resolves: Coverity CID 1645555
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20260311021319.1053774-1-jamin_lin@aspeedtech.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This function will shortly be used to help find if there is a route to a
device, serving an HPA, under a particular fixed memory window. Rather than
having that new use case subtract the base address in the caller, only to
add it again in cxl_cfmws_find_device(), push the responsibility for
calculating the HPA to the caller.
This also reduces the inconsistency in the meaning of the hwaddr addr
parameter between this function and the calls made within it that access
the HDM decoders that operating on HPA.
Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Gregory Price <gourry@gourry.net>
Tested-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com>
Message-ID: <20260318171918.146-2-alireza.sanaee@huawei.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
These devices are only used by the RISC-V targets, which are
only built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN
definition expand to DEVICE_LITTLE_ENDIAN (besides, the
DEVICE_BIG_ENDIAN case isn't tested). Simplify directly
using DEVICE_LITTLE_ENDIAN.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20260318103122.97244-2-philmd@linaro.org>
nmap / ncat has a somewhat problematic license (e.g. saying claiming
that derived work is also considered for software that "is designed
specifically to execute Covered Software and parse the results", e.g.
by executing ncat from your own program, you might already fall into
this category) - so for example in openSUSE 16, you can only find it
in the "non-OSS" repository.
We are currently only using it in the migration functional test, and
that likely does not fall into this "derived work" category yet (since
it is also doing some other stuff), but still, to be safe, we should
move away from using it now.
Unfortunately, switching to one of the other flavors of netcat is
also not a real option (see commit f700abbbeb),
but socat should be a solid replacement here instead.
To avoid that someone else easily uses ncat again, let's also remove
it from our container files now.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260316183016.239526-1-thuth@redhat.com>
Message-ID: <20260320155107.2143191-9-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The first version of openSUSE 15 has been released in 2018, and
according to our support policy, we "support the most recent major
version at all times for up to five years after its initial release."
Since openSUSE 16 has been released a while ago, and openSUSE is
clearly older than 5 years already, it's time to update to version 16
now.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20260316135407.209072-3-thuth@redhat.com>
Message-ID: <20260320155107.2143191-7-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This extends the VBSA test to run the linux tests. The sysarch-acs
test suite does provide some pre-built images which is good because
the tests require a patched kernel. However due to the structure of
the image we need to jump one or two hoops to get something useful:
- download and double decompress (zip then xz) the image
- navigate grub to launch the Linux Execution Environment
- shutdown the system once tests are done
- extract the logs from the MSDOS file system and parse them
It does make the code a bit ugly but it works for me at least. So far
the subset of tests run is limited but that might be solved by adding
some more devices to the PCIe bus to exercise the SMMU behaviour.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260320155107.2143191-5-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
We have a lot of TCG tests now which can be fiddly if we just want to
check one particular test type across the targets. Introduce
TCG_TEST_FILTER to allow this:
make check-tcg TCG_TEST_FILTER=gdb
to run all the gdb tests across the suites.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260320155107.2143191-2-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The pci_piix_realize() function's use of qemu_allocate_irqs()
results in a memory leak:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x61045c7a1a43 in malloc (/home/pm215/qemu/build/san/qemu-system-mips+0x16f8a43) (BuildId: aa43d3865e0f1991b1fc04422b5570fe522b6fa7)
#1 0x724cc3095ac9 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62ac9) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#2 0x61045db72134 in qemu_extend_irqs /home/pm215/qemu/build/san/../../hw/core/irq.c:77:51
#3 0x61045cd7bf49 in pci_piix_realize /home/pm215/qemu/build/san/../../hw/isa/piix.c:318:35
#4 0x61045cf4533e in pci_qdev_realize /home/pm215/qemu/build/san/../../hw/pci/pci.c:2308:9
#5 0x61045db6cbca in device_set_realized /home/pm215/qemu/build/san/../../hw/core/qdev.c:523:13
#6 0x61045db86bd9 in property_set_bool /home/pm215/qemu/build/san/../../qom/object.c:2376:5
#7 0x61045db81c5e in object_property_set /home/pm215/qemu/build/san/../../qom/object.c:1450:5
#8 0x61045db8e2fc in object_property_set_qobject /home/pm215/qemu/build/san/../../qom/qom-qobject.c:28:10
#9 0x61045db8258f in object_property_set_bool /home/pm215/qemu/build/san/../../qom/object.c:1520:15
#10 0x61045db687aa in qdev_realize_and_unref /home/pm215/qemu/build/san/../../hw/core/qdev.c:283:11
#11 0x61045d892e21 in mips_malta_init /home/pm215/qemu/build/san/../../hw/mips/malta.c:1239:5
(The i386 PC sets the has-pic property to 'false', so this only
affects the MIPS Malta board.)
Fix this by embedding the i8259 irq in the device state instead of
allocating it. This is a similar fix to the one we used for vt82c686
in commit 2225dc562a, except that we use qemu_init_irq_child()
instead of qemu_init_irq(). The behaviour is identical except that
the _child() version avoids what would be a leak if we ever
unrealized the device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Message-id: 20260309171258.1905205-1-peter.maydell@linaro.org
Commit d751921cff ("hw/arm/omap1: Remove omap_badwidth_*
implementations") removed the last use of the legacy ldst_phys()
API. Set the TARGET_NOT_USING_LEGACY_LDST_PHYS_API variable to
hide the legacy API to the ARM / Aarch64 binaries, avoiding further
API uses to creep in.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260319104414.66367-1-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Unconditionally enable some more enlightenments for whpx. In
particular, linux uses AccessVpRegs without checking availability and
panics if it's not there, so it's important to expose it.
We also had a duplicate line where we set AccessHypercallRegs = 1
twice; remove the duplicate.
Microsoft’s VMM exposes SyncContext on arm64 and FastHypercallOutput
regardless of architecture unconditionally, so add those two to match
that configuration.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Message-id: 20260314221529.47841-4-mohamed@unpredictable.fr
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
configure has a variable default_cflags, which was originally added
in commit bafe78ad3b ("contrib/plugins: use an independent
makefile") as part of it setting up the build environment for
contrib/plugins, which at the time used make. However, we now build
the plugins with meson, and in commit 55c84a72ab ("contrib/plugins:
remove Makefile for contrib/plugins") we dropped the logic from
configure that does that makefile setup, leaving default_cflags
as an unused variable.
shellcheck helpfully reports this:
default_cflags='-O0 -g'
^------------^ SC2034 (warning): default_cflags appears unused. Verify use (or export if used externally).
Remove the unused variable.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260317120215.2075164-1-peter.maydell@linaro.org
In commit 62272f9f88 we changed some uses of fixed char arrays
to call g_strdup_printf() instead. In one place I made a silly
error where in changing
sprintf(name, "fmt string", ...)
to
name = g_strdup_printf("fmt string", ...)
I forgot to delete "name" from the argument list.
Luckily Coverity spotted this (as CID 1645771) because at this
point "name" is NULL and passing g_strdup_printf() a NULL first
argument is not valid.
We didn't notice the mistake in testing or CI because this bit of
code is only run if on an AArch64 host with KVM and SVE available.
Correct the error by removing the stray function argument.
Fixes: 62272f9f88 ("tests/qtest/arm-cpu-features: Use g_strdup_printf() instead of char arrays")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-id: 20260317111121.2062455-1-peter.maydell@linaro.org
Currently some heuristics are used to locate the build dir, if the
MESON_BUILD_ROOT environment variable is not set. These are not
entirely accurate, however, especially if the developer is using
nested sub-dirs under $PWD/build/...
Since the introduction of the 'run' script, we can ensure any
direct execution of the tests will have MESON_BUILD_ROOT set.
Meanwhile when meson runs the test it will also have this env
set. The only gap is when running pre-caching, and that is easily
fixed to set MESON_BUILD_ROOT.
It can thus be assumed that MESON_BUILD_ROOT will always be set
in any supported execution scenario, which allows the heuristics
to be removed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260310114756.146083-3-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When running functional tests directly there are some heuristics
to figure out where the build directory lives, along with the
possibility to override the logic by setting the QEMU_BUILD_DIR
env variable. This env var is set as part of the test env when
run via Meson but not when run directly.
A particular flaw with the currently logic is that it silently
uses the wrong location when the build directory is a sub-dir
under "./build", which is a common usage scenario for some devs.
With the recent introduction of the 'run' script, we now have
the MESON_BUILD_ROOT env variable set unconditionally, so we
can rely on that from the functional tests to get the correct
location in all scenarios.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260310114756.146083-2-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
QEMU currently crashes when introspecting the sun4u-iommu device from the
command line interface:
$ ./qemu-system-sparc64 -display none -device sun4u-iommu,help
qemu-system-sparc64: ../../devel/qemu/system/physmem.c:1401:
register_multipage: Assertion `num_pages' failed.
Aborted (core dumped)
There does not seem to be a compelling reason for initializing the
memory regions from the instance_init function, so let's simply move
the code into a realize() function instead to fix this issue.
Reported-by: Markus Armbruster <armbru@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260317085839.445178-1-thuth@redhat.com>
QEMU currently crashes when introspecting the sun4m-iommu device from the
command line interface:
$ ./qemu-system-sparc -display none -device sun4m-iommu,help
qemu-system-sparc: ../../devel/qemu/system/physmem.c:1401:
register_multipage: Assertion `num_pages' failed.
Aborted (core dumped)
There does not seem to be a compelling reason for initializing the
memory regions from the instance_init function, so let's simply move
the code into a realize() function instead to fix this issue.
Reported-by: Markus Armbruster <armbru@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260317084450.442071-1-thuth@redhat.com>
