Was removed in 2c08624 but it's still useful for
Windows 10 so reintroduce it there.
And this time, actually make it work by reporting
the hypervisor bit in CPUID.
Pretend to be vmware to be able to use vmport's functionality.
If the vmware frequency leaf is disabled, pretend to be
KVM, with the only capability reported being X2APIC support.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Link: https://lore.kernel.org/r/20260422214225.2242-7-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Introduce a configurable poll-weight parameter for adaptive polling
in IOThread. This parameter replaces the hardcoded POLL_WEIGHT_SHIFT
constant, allowing runtime control over how much the most recent
event interval affects the next polling duration calculation.
The poll-weight parameter uses a shift value where larger values
decrease the weight of the current interval, enabling more gradual
adjustments. When set to 0, a default value of 3 is used (meaning
the current interval contributes approximately 1/8 to the weighted
average).
This patch also removes the hardcoded default value checks from
adjust_polling_time(). Instead, poll-grow, poll-shrink, and
poll-weight now use default values initialized in iothread.c
during IOThread creation.
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260423195918.661299-4-jhkim@linux.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Each TPM derived device has a @ppi_enabled field, itself
exposed as a QOM property. External layers (like the ACPI
subsystem) wanting to know whether a device implements PPI
has to check for the QOM property available. This can be
simplified by declaring a single field in the TPM interface.
Here we add such field to TPMIfClass, before converting each
TPM devices to use it in the following commits.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Message-Id: <20260317120241.16320-3-philmd@linaro.org>
Typedefs.h should only be used for really core types; QIgvm is
just an opaque struct that is defined in system/igvm-internal.h,
and the typedef itself can be placed simply in system/igvm.h.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Memory pull for 11.0 softfreeze
- BALATON's memory cleanups on _nomigrate MRs and else
- Phil's small constify series and else
- Marc-André's initial cleanup patches around ram discard manager
# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCaa8v2xIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wbiNgD/ZLS5BtRGva5eUQNXKkE3oOiXfDBkLyQ1
# BowQ12zjPZMBAOxrVvyGbpgsI5SOcSjsvFSsWLs1GFfHjVUAyCNusl4D
# =+4wZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon Mar 9 20:38:51 2026 GMT
# gpg: using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg: issuer "peterx@redhat.com"
# gpg: Good signature from "Peter Xu <xzpeter@gmail.com>" [marginal]
# gpg: aka "Peter Xu <peterx@redhat.com>" [marginal]
# gpg: WARNING: The key's User ID is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D D1A9 3B5F CCCD F3AB D706
* tag 'staging-pull-request' of https://gitlab.com/peterx/qemu:
system/memory: Have memory_region_type() correctly describe containers
system/xen: Constify various MemoryRegion arguments
system/memory: Constify various MemoryRegion arguments
system/ramblock: Constify various RAMBlock arguments
kvm: replace RamDicardManager by the RamBlockAttribute
system/memory: minor doc fix
virtio-mem: use warn_report_err_once()
memory: drop RamDiscardListener::double_discard_supported
system/rba: use DIV_ROUND_UP
memory: Factor out common ram ptr initialization
memory: Factor out common ram region initialization
memory: Add internal memory_region_register_ram function
memory: Shorten memory_region_init_ram_device_ptr and memory_region_init_rom_device
memory: Remove memory_region_init_ram_nomigrate()
hw/xtensa/xtfpga: Do not use memory_region_init_ram_nomigrate()
sun4m,sun4u,tcx: Do not use memory_region_init_ram_nomigrate()
memory: Remove memory_region_init_rom_nomigrate()
hw/display/{cg3.tcx}: Do not use memory_region_init_rom_nomigrate()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit 3607715a30 ("kvm: Introduce KVM irqchip change notifier")
restricted the kvm_irqchip*notifier() declarations to target-specific
files, guarding them under the NEED_CPU_H (later renamed as
COMPILING_PER_TARGET) #ifdef check.
This however prohibit building the kvm-stub.c file once:
../accel/stubs/kvm-stub.c:70:6: error: no previous prototype for function 'kvm_irqchip_add_change_notifier' [-Werror,-Wmissing-prototypes]
70 | void kvm_irqchip_add_change_notifier(Notifier *n)
| ^
../accel/stubs/kvm-stub.c:74:6: error: no previous prototype for function 'kvm_irqchip_remove_change_notifier' [-Werror,-Wmissing-prototypes]
74 | void kvm_irqchip_remove_change_notifier(Notifier *n)
| ^
../accel/stubs/kvm-stub.c:78:6: error: no previous prototype for function 'kvm_irqchip_change_notify' [-Werror,-Wmissing-prototypes]
78 | void kvm_irqchip_change_notify(void)
| ^
Since nothing in these prototype declarations is target specific,
move them around to be generically available, allowing to build
kvm-stub.c once for all targets in the next commit.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-Id: <20260309174941.67624-2-philmd@linaro.org>
`stubs/igvm.c` includes `igvm-internal.h`, that in turn includes the igvm library.
This is required just for the QIgvm declaration and creates an
unnecessary dependency on the library.
Since igvm is not listed as a dependency of stubs, this results in build
failing when the library is not installed in a "well known" path of the
system.
Add a forward declaration for QIgvm and move the definition of
`qigvm_directive_madt` to `igvm.h` so that we can drop `igvm-internal.h` from
`stubs/igvm.c`.
Fixes: dea1f68a5c ("igvm: Fill MADT IGVM parameter field on x86_64")
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Message-ID: <20260309-master-v2-1-7e02f07a1096@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add function to check if the mapcache is enabled.
No functional change.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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>
