While most objects can perform all their cleanup in the finalizer
method, there can be interactions with other resources / subsystems
/ threads which require that some cleanup be performed on an user
creatable object before unparenting it and entering finalization.
The current 'can_be_deleted' method runs in the deletion path and
is intended to be used to block deletion. While it could be used
to perform cleanup tasks, its name suggests it should be free of
side-effects.
Generalize this by renaming it to 'prepare_delete', explicitly
allowing for cleanup to be provided. Existing users of 'can_be_deleted'
are re-written, which provides them with more detailed/tailored error
messages.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260706135824.2623960-2-berrange@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
We autodetect the presence of FPRCVT in the test cross compiler,
which is a recent feature in GCC and not supported by many distros
yet. If this is in place, we compile the existing fcvt.c test with
an extra compiler flag which uses the new SIMD instructions; the
output from the test is unchanged.
The existing [US]CVTF instructions do not have a test, so no new
tests are added for the SIMD versions. They have been tested manually
to check the new SIMD versions produce the same numerical results as
the existing versions.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
Message-id: 20260630-jmac-fprcvt-v3-6-f4840d5e0a7f@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Previously the machines/chips tested by qtest was till Power10, update
the tests to also test PowerNV11 and Power11 PNV Chip
Since if-else-if ladder was common pattern to get machine type,
implement pnv_get_machine_type so new processor cases can be implemented
in one location in pnv_get_machine_type
While at it, also add g_autofree to allocation by g_strdup_printf in
modified tests
Tested-by: Misbah Anjum N <misanjum@linux.ibm.com>
Reviewed-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260703085955.2318600-4-adityag@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Currently pnv-spi-seeprom-test was hardcoded to test the 4th chip in
pnv_chips (power10 as of now).
This requires ensuring to update the index when removing/adding entries
in pnv_chips, such as when Power8E or Power11 gets removed/added in
future commits.
Iterate over all the chips instead, similar to other tests in
pnv-xscom-test.c and pnv-host-i2c-test.c, but skip older chips, since
TYPE_PNV_SPI only exists from Power10 onwards, hence skip older machines
Tests all the pnv_chips similar to other qtests
Tested-by: Misbah Anjum N <misanjum@linux.ibm.com>
Reviewed-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20260703085955.2318600-3-adityag@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
In the past there have been hard to recreate issues where XIVE changes
cause qemu crashes due to multi-socket interrupts such as in [1].
Add a functional test explicitly to test whether remote interrupts work.
The test can also work as additional boot test for multi-socket boot,
initrd boot test, as well as a check for e1000e to be working in powernv,
though that's not a target goal, and are additional benefits.
>From docs/system/devices/net.rst:
In order to check that the user mode network is working, you can ping
the address 10.0.2.2 and verify that you got an address in the range
10.0.2.x from the QEMU virtual DHCP server.
Hence use 10.0.2.2 with ping.
[1]: https://lore.kernel.org/qemu-devel/baf6c854-832b-4a2e-922f-d34e6dadf821@redhat.com/
Tested-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Reviewed-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Tested-by: Misbah Anjum N <misanjum@linux.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260703085955.2318600-2-adityag@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Nothing in tree exercises IOTLB invalidation for any emulated vIOMMU:
the existing iommu-testdev tests only check one-shot translation, so a
regression that failed to flush a stale IOTLB entry would go unnoticed.
Add a test that drives the queued-invalidation path end to end
(vtd_process_inv_desc -> vtd_process_iotlb_desc ->
vtd_iotlb_{global,domain,page}_invalidate). For each
{legacy, scalable-slt, scalable-flt} x {global, domain, page}
combination it:
1. maps IOVA -> PA_A and DMAs, populating the IOTLB;
2. rewrites the leaf PTE to PA_B *without* invalidating and DMAs
again, asserting the stale entry is still served (MISMATCH);
3. submits the IOTLB invalidation plus a wait descriptor, then DMAs
and asserts the fresh page walk now reaches PA_B.
Step 2 makes the flush observable: it fails loudly if the IOTLB
is not actually caching the first translation.
For scalable first-level (flt), QEMU keeps first- and second-level
mappings in a single IOTLB that the legacy VTD_INV_DESC_IOTLB descriptor
flushes for every level, so the test uses that descriptor across all
modes. PASID-selective invalidation (VTD_INV_DESC_PIOTLB, vtd_piotlb_*)
is a separate path and is left for a follow-up.
It also adds three page-selective cases that cache a second page and check
its fate after invalidating the first: for second-level (legacy, scalable-slt)
the second page survives, while for first-level (scalable-flt) QEMU flushes all
first-stage entries of the domain, so it does not. This distinguishes a
page-selective flush from a domain-wide or global one.
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260703072200.463082-4-junjie.cao@intel.com>
Add the building blocks a queued-invalidation test needs on top of the
existing translation helpers:
- qvtd_leaf_pte_addr() / qvtd_make_leaf_pte() let a test locate and
rewrite the leaf PTE built by qvtd_setup_translation_tables() without
re-deriving the page-table index or leaf attributes by hand. The
attributes reuse qvtd_get_fl_pte_attrs()/qvtd_get_pte_attrs() so the
first- and second-level leaf formats stay defined in one place.
- qvtd_submit_iotlb_global_inv() / _domain_inv() / _page_inv() write an
IOTLB Invalidation Descriptor (global / domain-selective /
page-selective) into the Invalidation Queue and advance IQT_REG.
- qvtd_submit_inv_wait_and_poll() submits an Invalidation Wait
Descriptor with Status Write and polls the status word with a bounded
retry loop, asserting on timeout.
No caller yet; used by the IOTLB invalidation test that follows.
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260703072200.463082-3-junjie.cao@intel.com>
iommu-intel-test.c keeps the iommu-testdev PCI setup (save_fn(),
setup_qtest_pci_device()) and the VT-d command-line / capability
helpers (qvtd_iommu_args(), qvtd_check_caps()) as file-local statics.
A second Intel IOMMU test would have to copy them, which defeats the
purpose of the shared qos-intel-iommu module.
Move them into qos-intel-iommu so sibling tests can reuse them:
save_fn() becomes qvtd_save_pci_dev() and setup_qtest_pci_device()
becomes qvtd_setup_qtest_pci_device(); qvtd_iommu_args() and
qvtd_check_caps() keep their names.
No functional change: iommu-intel-test now calls the public
qvtd_setup_qtest_pci_device() instead of its file-local copy.
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260703072200.463082-2-junjie.cao@intel.com>
Add a qtest that reads the "etc/e820" fw_cfg table and checks its
structural invariants: the file is a whole number of e820 entries and
every entry has a non-zero length. The baseline q35 case asserts the
guest sees RAM and, with no sp-mem device, no SOFT_RESERVED range.
Signed-off-by: FangSheng Huang <FangSheng.Huang@amd.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260623075051.3797975-10-FangSheng.Huang@amd.com>
Populate the expected ACPI blobs for the sp-mem test and clear the
allowed-diff list.
SRAT memory-affinity entries for the device_memory window (q35,
-m 128M,maxmem=1G, sp0 on node 1 and sp1 on node 2, each 128M):
Proximity Domain : 1 Base : 0x100000000 Length : 0x08000000 (Enabled)
Proximity Domain : 2 Base : 0x108000000 Length : 0x08000000 (Enabled)
Proximity Domain : 2 Base : 0x110000000 Length : 0x128000000 (Hot Pluggable)
Each sp-mem device gets an ENABLED entry at its own proximity domain;
the remaining device_memory window is covered by a HOTPLUGGABLE
placeholder at the highest proximity domain.
(DSDT.spmem differs from the base only by the memory-hotplug AML
enabled by -m,maxmem.)
Signed-off-by: FangSheng Huang <FangSheng.Huang@amd.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260623075051.3797975-9-FangSheng.Huang@amd.com>
Add a q35 bios-tables-test case that boots two sp-mem devices on
distinct NUMA nodes within the device_memory window, exercising the
per-kind SRAT partition (per-device ENABLED entries plus HOTPLUGGABLE
placeholders for the remaining sub-ranges).
Signed-off-by: FangSheng Huang <FangSheng.Huang@amd.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260623075051.3797975-8-FangSheng.Huang@amd.com>
RISC-V PR for 11.1
* Fix IMSIC CSR write and add tests
* Parametrise debug trigger number
* Add 'svbare' satp-mode
* Fix RINTC PLIC context ID for KVM
* Avoid abort when reading vtype before env->xl is set
* Skip reset for KVM irqchip
* Skip FP/Vector sync on KVM_PUT_RUNTIME_STATE
* More FDT cleanups (PLIC)
* Make FCTL.BE in IOMMU read only 0
* Check DC.TC reserved bits in IOMMU
* Apply UXL WARL handling to vsstatus
* Set cmd_ill IOFENCE.C if rsvp bits are set in IOMMU
* Set RISCV_IOMMU_FQ_HDR_PV appropriately
* Fix MSI MRIF IOMMU interrupt-pending offset
* Report QEMU CPU archid as 42
* Check PMP before updating PTE
* Add the Tenstorrent Atlantis machine
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmpE6SoACgkQr3yVEwxT
# gBOxNQ//bI4BvnT65Kd2UNMgtAwwPPcehpsyPzC2S3BcflniXQL+fV6sQ7IreKta
# 6dclp/v5v+yhbB4bd/E1s/UPOF3YD4A9noUFifIhymBkafmqA4YRNsvPByeGiSD8
# xVkHhX5qUT9NW5wKnivEDjO8mndBMRm5YEXQ6uT5ulUsZr3Ir8wPOCJITZ8ZqKwb
# 6dbbXStf1aTIBzu53KaNhNpi9DQqKV5UeV7CiSuhuwWU0qmVg1RAZMg9X3oB80rE
# WpWqH0rg9Z0Cn+3XL+oKSzbLD5SrrTV+Ohq+K8zT2rEk+hIXOE3shAPm2xfTT9Q2
# g65nBOf2UmNWeHlvn3XC2LtmIWq10/A78ogGgm4XwHx8TXIeA2KIKboyS8T37XAb
# NwUllq9LRtfDVtDevpiTn6t7Oa7TC8zrxDJTT1rg/p+3D6MdfkonifwJJgVAwfuG
# NF7R2iePKPQliWr1hi6W+ghzQMRFXgNBwUNOL39/BQguy5IqvNmSk6ovhl8IFocf
# aXGh9U35DqgrsUvMa/7Fgf4uI2QNhERBGJrHfL0SPZ82sKb5CTrMw9URwg0DFnEF
# 8v/zQ9xL4eF0uZn0OtaNlLXRCblDxcHSgecwix9Vip5toFIc1P8ar9FX98Zd/H5l
# UD/a3ENtiwb6hnKhZ+45iM/NIFJeUK7A0944VnQzx00tA06wJLw=
# =a4hl
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 01 Jul 2026 12:17:14 CEST
# gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [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: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013
* tag 'pull-riscv-to-apply-20260701' of https://github.com/alistair23/qemu: (39 commits)
hw/riscv/riscv-iommu.c: always fault with SADE=0 and A=0
hw/riscv/atlantis: Add some i2c peripherals
hw/riscv/atlantis: Integrate i2c controllers
hw/i2c: Add DesignWare I2C Controller
tests/functional/riscv64: Add tt-atlantis tests
hw/riscv/atlantis: Ensure OpenSBI has a non-zero next_addr
hw/riscv: Add Tenstorrent Atlantis machine
target/riscv: tt-ascalon: Enable Zkr extension
hw/riscv/aia: Configure stride for the M-mode IMSIC
hw/riscv/aia: Provide number of irq sources
hw/riscv/virt: Move AIA initialisation to helper file
hw/riscv/boot: Account for discontiguous memory when loading firmware
hw/riscv/boot: Describe discontiguous memory in boot_info
target/riscv: Check PMP before updating PTE
target/riscv: Report QEMU CPU archid as 42
hw/riscv/riscv-iommu.c: fix MSI MRIF interrupt-pending offset
hw/riscv/riscv-iommu.c: set RISCV_IOMMU_FQ_HDR_PV appropriately
hw/riscv/riscv-iommu: set cmd_ill IOFENCE.C rsvp bits are set
target/riscv: Apply UXL WARL handling to vsstatus
hw/riscv/riscv-iommu: check DC.TC reserved bits
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Add coverage of the riscv64 virt machine's Advanced Interrupt
Architecture models. With this the APLIC and IMSIC models are used by
Linux, catching regressions.
This test requires a kernel >= 6.10, as AIA drivers were added to Linux
in 6.10.
Boot time is ~5s on a laptop.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260617054034.1020724-4-joel@jms.id.au>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
The published tuxrun kernel is 6.4 which predates the introduction of
AIA support in Linux. Update it to a 6.11 kernel, the newest build
on the tuxrun site.
Boot times on a laptop are slightly longer but still reasonable:
| v6.4.16 | v6.11.9
---------------------|---------|--------
test_riscv64 | 4.82s | 5.56s
---------------------|---------|--------
test_riscv64_maxcpu | 4.94s | 5.30s
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260617054034.1020724-3-joel@jms.id.au>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
win-dmp becomes available only once the guest exposes a Windows dump
header through vmcoreinfo. Forge exactly such a note (an ELF note
header followed by a WinDumpHeader64 carrying the PAGE/DU64
signatures, the layout a Windows guest with the QEMU vmcoreinfo writer
produces), place it in guest RAM, point the vmcoreinfo device at it via
fw_cfg, and check that win-dmp flips from unavailable to available.
This exercises win_dump_available()'s positive path without a real
Windows guest. It only covers availability reporting; the actual
win-dmp generation (create_win_dump()) needs real Windows kernel
structures and is not exercised here.
The test is registered only on x86_64 with a vmcoreinfo device present.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260619101834.228432-8-den@openvz.org>
Requesting the Windows crashdump format (win-dmp) on a guest that does not
expose a Windows dump header through vmcoreinfo must be rejected, not
silently turned into a bogus dump. Add a test that asks for win-dmp on a
plain VM and checks the request fails with "invalid vmcoreinfo note size"
and that the VM stays usable afterwards (a subsequent ELF dump succeeds).
The test is x86_64 only, where win_dump_available() performs this check.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260619101834.228432-7-den@openvz.org>
There is currently almost no coverage for the dump-guest-memory QMP
command beyond the test-hmp smoke test. Add a qtest that runs on a bare
machine (no guest OS) and checks:
- query-dump-guest-memory-capability always advertises 'elf';
- an ELF dump is produced and starts with the ELF magic;
- a non-raw kdump dump is emitted in makedumpfile flattened format;
- a raw kdump dump starts with the on-disk KDUMP header;
- an unknown protocol is rejected without killing the VM, and dumping
still works afterwards.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20260619101834.228432-6-den@openvz.org>
Analogue to the previously added 3 synth tests, add (similar) 3 test
cases using the "local" fs driver to verify correct xattr FID limit
enforcement of 9pfs server with a real filesystem.
These 3 new local tests use the shared test code of the previously
added 3 synth tests. The only difference is that the local fs driver
does not expose the current internal xattr FID counter, so we can't
verify this with the local tests.
This is a slow test (may take several seconds) and therefore
registered as "slow" test and not running by default.
Use -m slow to run this test.
Link: https://lore.kernel.org/qemu-devel/d23fa874df4f474ee7cbe738a35c1483426057f0.1781361555.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Add 3 test cases to verify correct xattr FID limit enforcement of
9pfs server.
- 1. test with default max_xattr=1024
- 2. test with custom max_xattr=100
- 3. test with unlimited max_xattr=0
These are tests using the synth driver. Advantage: by using the
synth driver the tests cannot only check when the xattr FID limit
kicks in (server would return an Rlerror response with ENOSPC),
but can also validate the current 9p server internal xattr FID
counter at any moment.
This is a slow test (may take several seconds) and therefore
registered as "slow" test and not running by default.
Use -m slow to run this test.
Link: https://lore.kernel.org/qemu-devel/540c51faa074d9dd736bbf2170084a12288e23ef.1781361555.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Increase the maximum 9P message size ('msize') of 9p test client from
4k to 32k to support larger messages.
This is needed for the xattr tests being added with the subsequent
patches which are going to transmit xattrs of size 8k. It would have
also been possible to send them in multiple chunks, however let's not
overcomplicate things.
This new msize is still reasonable small compared to common msize
values on production systems.
Link: https://lore.kernel.org/qemu-devel/2dcb1243c80ea97d085af5171785850cf012be36.1781361555.git.qemu_oss@crudebyte.com
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
This allows us to record information about exceptions using a small
area of memory, and continue with the test so it can verify exceptions
have been taken where expected.
LOGGING_VECTOR_TABLE is added to switch this on, and vec_logging_boot.o
is built from boot.S with this flag. Since boot.o is created for multiple
test targets, we have to build a separate object and selectively link this
new vec_logging_boot.o into particular test binaries.
Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20260618-jmac-gpc3b-v3-5-353e546067e7@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
