When new vcpu file descriptors are created and bound to the new kvm file
descriptor as a part of the confidential guest reset mechanism, various
subsystems needs to know about it. This change adds notifiers so that various
subsystems can take appropriate actions when vcpu fds change by registering
their handlers to this notifier.
Subsequent changes will register specific handlers to this notifier.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-31-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Various subsystems might need to take some steps before the KVM file descriptor
for a virtual machine is changed. So a new boolean attribute is added to the
vmfd_notifier structure which is passed to the notifier callbacks.
vmfd_notifer.pre is true for pre-notification of vmfd change and false for
post notification. Notifier callback implementations can simply check
the boolean value for (vmfd_notifer*)->pre and can take actions for pre or
post vmfd change based on the value.
Subsequent patches will add callback implementations for specific components
that need this pre-notification.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-9-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A notifier callback can be used by various subsystems to perform actions when
KVM file descriptor for a virtual machine changes as a part of confidential
guest reset process. This change adds this notifier mechanism. Subsequent
patches will add specific implementations for various notifier callbacks
corresponding to various subsystems that need to take action when KVM VM file
descriptor changed.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-8-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This change adds common kvm specific support to handle KVM VM file descriptor
change. KVM VM file descriptor can change as a part of confidential guest reset
mechanism. A new function api kvm_arch_on_vmfd_change() per
architecture platform is added in order to implement architecture specific
changes required to support it. A subsequent patch will add x86 specific
implementation for kvm_arch_on_vmfd_change() as currently only x86 supports
confidential guest reset.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-6-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After the guest KVM file descriptor has changed as a part of the process of
confidential guest reset mechanism, existing memory needs to be reattached to
the new file descriptor. This change adds a helper function ram_block_rebind()
for this purpose. The next patch will make use of this function.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-5-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
As a part of the confidential guest reset process, the existing encrypted guest
state must be made mutable since it would be discarded after reset. A new
encrypted and locked guest state must be established after the reset. To this
end, a new boolean member per confidential guest support class
(eg, tdx or sev-snp) is added that will indicate whether its possible to
rebuild guest state:
bool can_rebuild_guest_state;
This is true if rebuilding guest state is possible, false otherwise.
A KVM based confidential guest reset is only possible when
the existing state is locked but its possible to rebuild guest state.
Otherwise, the guest is not resettable.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20260225035000.385950-3-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Nitro Enclaves are a confidential compute technology which
allows a parent instance to carve out resources from itself
and spawn a confidential sibling VM next to itself. Similar
to other confidential compute solutions, this sibling is
controlled by an underlying vmm, but still has a higher level
vmm (QEMU) to implement some of its I/O functionality and
lifecycle.
Add an accelerator to drive this interface. In combination with
follow-on patches to enhance the Nitro Enclaves machine model, this
will allow users to run a Nitro Enclave using QEMU.
Signed-off-by: Alexander Graf <graf@amazon.com>
Link: https://lore.kernel.org/r/20260225220807.33092-5-graf@amazon.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove the need of per-target QEMU_ARCH. Define the
QEMU_ARCH_* constants based on SYS_EMU_TARGET_* ones,
themselves already exposed via target_arch(), allowing
to check the current target is included in @arch_bitmask.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260213175032.32121-5-philmd@linaro.org>
qemu_arch_available() is used to check if a broadly available
feature should be exposed to a particular set of target
architectures.
Since its argument is a mask of bits, rename it as @arch_bitmask.
We have less than 32 target architectures so far, so restrict it
to the uint32_t type.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260213175032.32121-2-philmd@linaro.org>
The replay infrastructure shouldn't depend on internals of audio/.
(st_sample is an internal implementation detail and could be different)
Let audio drive the audio samples recording/replaying.
Notice also we don't need to save & restore the internal ring "wpos",
all replay should care about is the number of samples and the samples.
Bump the replay version.
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This change removes userland code that worked around a restriction
in the mshv driver in the 6.18 kernel: regions from userland
couldn't be mapped to multiple regions in the kernel. We maintained a
shadow mapping table in qemu and used a heuristic to swap in a requested
region in case of UNMAPPED_GPA exits.
However, this heuristic wasn't reliable in all cases, since HyperV
behaviour is not 100% reliable across versions. HyperV itself doesn't
prohibit to map regions at multiple places into the guest, so the
restriction has been removed in the mshv driver.
Hence we can remove the remapping code. Effectively this will mandate a
6.19 kernel, if the workload attempt to map e.g. BIOS to multiple
reagions. I still think it's the right call to remove this logic:
- The workaround only seems to work reliably with a certain revision
of HyperV as a nested hypervisor.
- We expect Direct Virtualization (L1VH) to be the main platform for
the mshv accelerator, which also requires a 6.19 kernel
This reverts commit efc4093358.
Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Acked-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
Tested-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Link: https://lore.kernel.org/r/20260113153708.448968-1-magnuskulke@linux.microsoft.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Change terminology to match the KVM one, as APIC is x86-specific.
And move out whpx_irqchip_in_kernel() to make it usable from common
code even when not compiling with WHPX support.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
As of why: WHPX on arm64 doesn't have debug trap support as of today.
Keep the exception bitmap interface for now - despite that being entirely unavailable on arm64 too.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use the new acpi_build_madt_standalone() function to fill the MADT
parameter field.
The IGVM parameter can be consumed by Coconut SVSM [1], instead of
relying on the fw_cfg interface, which has caused problems before due to
unexpected access [2,3]. Using IGVM parameters is the default way for
Coconut SVSM across hypervisors; switching over would allow removing
specialized code paths for QEMU in Coconut.
Coconut SVSM needs to know the SMP configuration, but does not look at
any other ACPI data, nor does it interact with the PCI bus settings.
Since the MADT is static and not linked with other ACPI tables, it can
be supplied stand-alone like this.
Generating the MADT twice (during ACPI table building and IGVM processing)
seems acceptable, since there is no infrastructure to obtain the MADT
out of the ACPI table memory area.
In any case OVMF, which runs after SVSM has already been initialized,
will continue reading all ACPI tables via fw_cfg and provide fixed up
ACPI data to the OS as before without any changes.
The IGVM parameter handler is implemented for the i386 machine target
and stubbed for all others.
[1] https://github.com/coconut-svsm/svsm/pull/858
[2] https://gitlab.com/qemu-project/qemu/-/issues/2882
[3] https://github.com/coconut-svsm/svsm/issues/646
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-10-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Pass the full MachineState to the IGVM backend during file processing,
instead of just the ConfidentialGuestSupport struct (which is a member
of the MachineState).
This replaces the cgs parameter of qigvm_process_file() with the machine
state to make it available in the IGVM processing context.
We will use it later to generate MADT data there to pass to the guest
as IGVM parameter.
Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-8-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Move repeating code for finding the parameter entries in the IGVM
backend out of the parameter handlers into a common function.
A warning message is emitted in case a no parameter entry can be found
for a given index.
Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-6-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Move QIgvm and QIgvmParameter struct definitions from the source file
into an IGVM internal header file to allow implementing architecture
specific IGVM code in other places, for example target/i386/igvm.c.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Message-ID: <20260130054714.715928-5-osteffen@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add UserCreatableClass->complete callback function for igvm-cfg object.
Move file loading and parsing of the igvm file from the process function
to the new complete() callback function. Keep the igvm file loaded
after processing, release it in finalize() instead, so we parse it only
once.
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260126123755.357378-4-kraxel@redhat.com>
Add TYPE_RESETTABLE_INTERFACE to interfaces. Register callbacks for the
reset phases. Add trace points for logging and debugging. No
functional change, that will come in followup patches.
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260126123755.357378-3-kraxel@redhat.com>
Add a new igvm-internal.h header file. Structs and declarations which
depend on the igvm library header go into that file.
Also declare IgvmCfg in typedefs.h, so the type can be used without
including igvm header files.
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20260126123755.357378-2-kraxel@redhat.com>
target-arm queue:
* hw/arm/imx8mp-evk: Provide some defaults matching real hardware
* hw/intc: endianness fixes
* various: Clean up includes
* kernel-doc.py: sync with upstream Kernel v6.19-rc4
* scripts/clean-includes: Minor improvements; exclude list update
* docs/system/arm/imx8mp-evk: Avoid suggesting redundant CLI parameters
* docs/system/arm/xlnx-zynq.rst: Improve docs rendering
* docs: Be consistent about capitalization of 'Arm' (again)
* docs: Avoid unintended mailto: hyperlinks
* qemu-options.hx: Drop uses of @var
* qemu-options.hx: Improve formatting in colo-compare docs
# -----BEGIN PGP SIGNATURE-----
#
# iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmlzju4ZHHBldGVyLm1h
# eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3uU/D/9IHpo57UIHAF7vU9gsWm5k
# TxLl9PBw3ev2Uv6zWWza0wYZQF2ZcvqwMiU/AlBFuyJFyXTLocL3iN6Rsw+8kcjh
# jaq2hCtzSNJWj41CEU22l7iUfJ5PdOVdRYhhwlrQqxXDJj8Oj3plliRc6AL1EZYD
# mxAJ+YQ8pfJ/2ibO66sqwGMLjPsjCmmgfloTm/qFzk7QccQkPZKzDrC9CGGRmmRA
# tcdBGMtu+DOqpCRKIRul0S8ed2qaTecIK3+fUID0+qEzb10VWgFs/AAQiwLPkwyi
# RvMmIbC9lYVCnP+YC4HlvYMfd61V3lpzsUXgMIbdRZYsN/IlTVfetJUOVmn3LTQ/
# gGU0b+t6D/OZAt1L6toBngKVh89VPqbpGXEx4UMHCNIcvfI1Xo+HRT9ZV5WCw6b8
# sVKOZUwKs9ZbFAcrgBgskXp/5KWZAb92IFjwbfwxxl/2NRK3B3y7CDHBoOM/zQ9a
# rZ7rfJHhQVGR2+1QonNbpG0IFwbgs0zPQwBjPreGh6TWf2UiXvx1ku94Wxe2lA+5
# CPeju+swbFKRNjwSas6NZjJWazacohYG3nhmhF7HtcgX279BzIV0d+ZIl786Juls
# 4Vt4dPUxU/kHHZHjE52AZUS/opIy+UHAj0FKPAPpTrc7UfuHlY3gqoI7UfVpciau
# q3DqM7PlF2X91kw4xJ6JCA==
# =bE6w
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 24 Jan 2026 02:08:30 AM AEDT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [unknown]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [unknown]
# gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* tag 'pull-target-arm-20260123' of https://gitlab.com/pm215/qemu: (22 commits)
qemu-options.hx: Improve formatting in colo-compare docs
qemu-options.hx: Drop uses of @var
docs: avoid unintended mailto: hyperlinks
docs/system/arm/xlnx-zynq.rst: Improve docs rendering
hw/intc: avoid byte swap fiddling in gicv3 its path
hw/intc: declare GICv3 regions as little endian
hw/intc: declare GIC regions as little endian
hw/intc: declare NVIC regions as little endian
all: Clean up includes
misc: Clean up includes
bsd-user: Clean up includes
mshv: Clean up includes
scripts/clean-includes: Update exclude list
scripts/clean-includes: Give the args in git commit messages
scripts/clean-includes: Do all our exclusions with REGEXFILE
scripts/clean-includes: Make ignore-regexes one per line
scripts/clean-includes: Remove outdated comment
scripts/clean-includes: Allow directories on command line
docs: Be consistent about capitalization of 'Arm' (again)
kernel-doc.py: sync with upstream Kernel v6.19-rc4
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This commit was created with scripts/clean-includes:
./scripts/clean-includes '--git' 'all' '--all'
and manually edited to remove one change to hw/virtio/cbor-helpers.c.
All these changes are header files that include osdep.h or some
system header that osdep.h pulls in; they don't need to do this.
All .c should include qemu/osdep.h first. The script performs three
related cleanups:
* Ensure .c files include qemu/osdep.h first.
* Including it in a .h is redundant, since the .c already includes
it. Drop such inclusions.
* Likewise, including headers qemu/osdep.h includes is redundant.
Drop these, too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260116125830.926296-5-peter.maydell@linaro.org
This commit was created with scripts/clean-includes:
./scripts/clean-includes '--git' 'mshv' 'accel/mshv' 'target/i386/mshv' 'include/system/mshv.h'
All .c should include qemu/osdep.h first. The script performs three
related cleanups:
* Ensure .c files include qemu/osdep.h first.
* Including it in a .h is redundant, since the .c already includes
it. Drop such inclusions.
* Likewise, including headers qemu/osdep.h includes is redundant.
Drop these, too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260116125830.926296-2-peter.maydell@linaro.org
Guard the native endian definition we want to remove by surrounding
it with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Assign values to the enumerators so they stay unchanged.
Once a target gets cleaned we'll set the definition in the target
config, then the target won't be able to use the legacy API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-21-philmd@linaro.org>
Guard the native endian APIs we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-16-philmd@linaro.org>
Guard the native endian APIs we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Since all targets can check the definition, do not poison it.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20260109165058.59144-15-philmd@linaro.org>
