| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
# Conflicts:
# arch/arm64/include/asm/ptrace.h
# arch/arm64/include/asm/sysreg.h
# arch/arm64/kvm/hyp/nvhe/hyp-main.c
|
|
Add HW PTW feature when VM is created. This feature is detected firstly,
and enabled if it is available on the host machine. With HW PTW feature
enabled, refill exception will not happen and it is not necessary to set
TLB refill exception entry.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
* kvm-arm64/gicv5-7.4: (52 commits)
: \
: GICv5 IRS support, courtesy of Sascha Bischoff. From the cover letter:
:
: "This series builds on the initial vGICv5 support and adds support
: for the GICv5 IRS, as described by the GICv5 (EAC0) specification.
: With this, a GICv5 guest is no longer restricted to PPIs, and can make
: use of SPIs and LPIs as well."
: /
KVM: arm64: vgic-v5: Correctly handle host ISTE __le32 conversion
KVM: arm64: vgic-v5: Tidy-up programming of vpe descriptor address
KVM: arm64: vgic-v5: Correctly reset h_lpi_ist to NULL
KVM: arm64: vgic-v5: Drop __iomem attribute from {vmd,vpet}_base
KVM: selftests: Add VGICv5 sparse vCPU IDs test
KVM: selftests: Add VGICv5 IST save/restore coverage
KVM: selftests: Add VGICv5 LPI delivery tests
KVM: selftests: Add VGICv5 SPI injection tests
KVM: selftests: Add VGICv5 CPU sysreg attribute tests
KVM: selftests: Add VGICv5 USERSPACE_PPIS tests
KVM: selftests: Add VGICv5 IST attribute tests
KVM: selftests: Add VGICv5 IRS_REGS attribute tests
KVM: selftests: Add VGICv5 NR_IRQS attribute tests
KVM: selftests: Add VGICv5 IRS address attribute tests
Documentation: KVM: Add the VGICv5 IRS save/restore sequences
Documentation: KVM: Add docs for KVM_DEV_ARM_VGIC_GRP_IST
Documentation: KVM: Add KVM_DEV_ARM_VGIC_GRP_IRS_REGS to VGICv5 docs
Documentation: KVM: Document KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS for VGICv5
KVM: arm64: gic-v5: Implement save/restore mechanisms for ISTs
KVM: arm64: gic-v5: Add VGICv5 IST save/restore UAPI
...
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
* selftests: (83 commits)
KVM: selftests: Spell out UCALL in nested TSC scaling test's enums
KVM: selftests: Use GUEST_SYNC2() in nested TSC scaling test
KVM: selftests: Randomize L2's TSC offset in the nested TSC scaling test
KVM: selftests: Test non-zero TSC offset on SVM in nested TSC scaling test
KVM: selftests: Verify that KVM saturates L2 TSC freq on {under,over}flow
KVM: selftests: Test L1 "up" and L2 "down" in nested TSC scaling test
KVM: selftests: Sanity check KVM's default TSC freq in nested TSC scaling test
KVM: selftests: Explicitly pass TSC frequencies to guts of TSC scaling test
KVM: selftests: Use KVM's reported TSC KHz as L0's frequency (sanity checked)
KVM: selftests: Allow +/- 1 tolerance if expected TSC frequency is <100
KVM: selftests: Print out the failing L{0,1,2} level in nested TSC scaling test
KVM: selftests: Track L2 multiplier, not scale-up factor, in nested TSC test
KVM: selftests: Extract guts of nested TSC scaling test to helper function
KVM: selftests: Rename TSC freq checkers in nested TSC scaling test
KVM: selftests: Randomize L2's scale factor in nested TSC scaling test
KVM: selftests: Drop unnecessary use of PRIu64 in nested TSC scaling test
KVM: selftests: Drop redundant VMWRITE of TSC_MULTIPLIER_HIGH
KVM: selftests: Use KVM's pRNG to randomize L1's TSC ratio in TSC scaling test
KVM: x86: Allow userspace to set KVM's max supported guest TSC frequency
KVM: SVM: Fallback to the default TSC ratio if KVM tries to use a bad multiplier
...
|
|
* misc: (45 commits)
KVM: x86: Request event processing for exception VM-Exits
KVM: selftests: Add coverage for the EFER_LMSLE_MBZ defeature
KVM: selftests: Add module param API to check if nested virtualization is enabled
KVM: selftests: Rename svm_nested_clear_efer_svme to svm_nested_efer_test
KVM: x86: Honor the guest's EFER_LMSLE_MBZ
KVM: x86: Advertise EFER_LMSLE_MBZ when KVM disallows EFER.LMSLE
KVM: SVM: Add support for virtualizating Bus Lock Detect
KVM: SVM: Add a vCPU-aware helper to get supported DEBUGCTL bits
KVM: nSVM: Don't assume all active-low bits DR6 are fixed-1
KVM: nSVM: Open code check on LBR virtualization being enabled in vmcb12
KVM: nSVM: Disable LBRV in nested control cache when unsupported
KVM: SVM: Add helper to query if LBR virtualization needs to be enabled
KVM: x86: Kill off DR6_FIXED_1 to prevent future misuse
KVM: x86: Set guest's fixed-1 DR6 bits when delivering #DB payload
KVM: x86: Force fixed-1 bits in DR6 after synchronizing with hardware
KVM: Return an "unsigned long", not "u64" for the fixed-1 DR6 bits
KVM: x86: Rename kvm_dr6_fixed() => kvm_get_dr6_fixed_1()
KVM: x86: Preserve DR6.BLD (Bus Lock Detect) when delivering #DB payload
KVM: x86: Restrict saved GPA writes to hardware write faults
KVM: x86/pmu: Don't retry a counter whose config was rejected
...
|
|
Add coverage for KVM's virtualization of EFER_LMSLE_MBZ,
CPUID.80000008H:EBX[bit 20], which is set when the CPU does *not* support long
mode segment limits. Verify that KVM's enumeration of the defeature matches
the expectation derived from hardware plus kvm_amd's "nested" module param, so
that the assertion doesn't compare KVM's enumeration against itself, and that
WRMSR(EFER), nested VMRUN, and KVM_SET_SREGS reject EFER.LMSLE=1 if and only
if guest CPUID enumerates the defeature. Also verify that host-initiated
KVM_SET_MSRS is exempt from the check, as host-initiated writes skip guest
CPUID checks so that userspace can set MSRs before it sets guest CPUID.
Extend svm_nested_efer_test rather than add yet another test binary for a
single CPUID bit; the test already has the L1/L2 harness needed to exercise
EFER.LMSLE. Note, only a CPU that supports LMSLE, i.e. Rome and earlier,
exercises the emulation path; elsewhere KVM enumerates the defeature straight
from hardware.
Opportunistically drop the unnecessary #include of vmx.h.
Assisted-by: LLM
Signed-off-by: Jim Mattson <jmattson@google.com>
[sean: drop specific APM volume references, use common "nested" getter]
Link: https://patch.msgid.link/20260930212114.3500045-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
enabled
Add an API to check if the nested virtualization module param is enabled,
e.g. so that tests can verify KVM's own enumeration of the corresponding
CPU feature. Provide a big warning above the API to make it as obvious as
possible clear that tests should use "kvm_cpu_has(X86_FEATURE_VMX) ||
kvm_cpu_has(X86_FEATURE_SVM)" when checking for nested virtualization. It
doesn't really matter which method tests use, as KVM is supposed to keep
"nested" synchronized with VMX/SVM enumeration, but make the comment super
scary to try and prevent KVM selftests from having two different ways of
doing the same thing.
Note, the bool vs. int mess is intentional, because KVM's params are
terrible. kvm_amd.ko provides an "int", while kvm_intel.ko provides a
"bool".
Link: https://patch.msgid.link/20260930212114.3500045-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Delete guest_snprintf() as it isn't used, has never been used, and in all
likelihood will never be used. Because variadic functions can't pass along
va_args verbatim, guest_snprintf() can't be used as-is by things like
ucall_fmt(). guest_snprintf() could be used to dedup the ucall code by
turning it into a macro, but that would still require implicitly consuming
the caller's variadic arguments and would risk creating variable shadows,
i.e. introduces fragility for very little benefit.
No functional change intended.
Link: https://lore.kernel.org/all/20260930002238.649421F000FF@smtp.kernel.org
Signed-off-by: Gokul K <gokul02k@gmail.com>
Closes: https://lore.kernel.org/all/20260918113631.634233-4-gokul02k@gmail.com
Link: https://patch.msgid.link/20260918113631.634233-4-gokul02k@gmail.com
[sean: massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
lib/io.c has outlived its purpose. test_read() has exactly one caller,
lib/elf.c; test_write() has none at all; and test_seq_read() is a
declaration in test_util.h with no definition anywhere in the tree.
Both surviving helpers open with
TEST_ASSERT(count >= 0, "Unexpected count, count: %li", count);
which can never fire, because @count is a size_t. Building with -Wextra
points this out:
lib/io.c:51:27: warning: comparison of unsigned expression in '>= 0'
is always true [-Wtype-limits]
lib/io.c:128:27: warning: comparison of unsigned expression in '>= 0'
is always true [-Wtype-limits]
The comment above each assertion is worse than the assertion itself: it
cites the read(2) and write(2) manpages to claim that a count of zero is
allowed, but a zero count lands in "case 0" and fails the test outright.
The helper has never accepted what the comment promises.
Move test_read() into elf.c as a static elf_read(), named for what it
does rather than reading as "test the read() syscall", and assert that
@count is non-zero, which is what the code has always required and what
every caller already passes. Drop the commentary describing retry
behaviour that the code makes obvious. Nothing is then left in
lib/io.c, so remove the file along with test_write() and the stale
test_seq_read() declaration.
No functional change intended.
Suggested-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/all/aqxNbR9u5F1sqB3p@google.com
Signed-off-by: Gokul K <gokul02k@gmail.com>
Link: https://patch.msgid.link/20260918054420.338842-1-gokul02k@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
vcpu_set_cpuid_maxphyaddr() is declared in include/x86/processor.h and
defined nowhere. The declaration is the only mention of the name in
tools/testing/selftests, so nothing has ever been able to call it.
No Fixes: tag: a prototype for a function that does not exist cannot
have regressed anything, and there is nothing to backport.
No functional change intended.
Signed-off-by: Gokul K <gokul02k@gmail.com>
Link: https://patch.msgid.link/20260918113631.634233-3-gokul02k@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
These are needed by the VFIO mlx5 selftest in the following patches,
which includes some headers from mlx5 and also needs a few more
MMIO-related features.
- DECLARE_FLEX_ARRAY in new tools/include/linux/stddef.h (wraps
existing __DECLARE_FLEX_ARRAY from uapi/linux/stddef.h)
- dma_wmb/dma_rmb barriers: x86 uses compiler barrier
(DMA-coherent), arm64 uses dmb oshst/oshld (outer-shareable for
device visibility), generic fallback uses wmb/rmb
- ioread32be/iowrite32be in tools/include/asm-generic/io.h for
big-endian MMIO register access
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/5-v7-c6d30e8ce1e4+3dfa6-mlx5st_jgg@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
The TEST_EXPECT_SIGBUS macro is not thread-safe as it uses a global
sigjmp_buf and installs a global SIGBUS signal handler. If multiple threads
execute the macro concurrently, they will race on installing the signal
handler and stomp on other threads' jump buffers, leading to incorrect test
behavior.
Make TEST_EXPECT_SIGBUS thread-safe with the following changes:
Share the KVM tests' global signal handler. sigaction() applies to all
threads; without sharing a global signal handler, one thread may have
removed the signal handler that another thread added, hence leading to
unexpected signals.
The alternative of layering signal handlers was considered, but calling
sigaction() within TEST_EXPECT_SIGBUS() necessarily creates a race. To
avoid adding new setup and teardown routines to do sigaction() and keep
usage of TEST_EXPECT_SIGBUS() simple, share the KVM tests' global signal
handler.
Opportunistically rename report_unexpected_signal to
catchall_signal_handler.
To continue to only expect SIGBUS within specific regions of code, use a
thread-specific variable, expecting_sigbus, to replace installing and
removing signal handlers.
Make the execution environment for the thread, sigjmp_buf, a
thread-specific variable.
As part of TEST_EXPECT_SIGBUS(), assert the prerequisite for this setup,
that the current signal handler is the catchall_signal_handler.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-41-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Introduce vm_mem_set_memory_attributes(), which handles setting of memory
attributes for a range of guest physical addresses, regardless of whether
the attributes should be set via guest_memfd or via the memory attributes
at the VM level.
Refactor existing vm_mem_set_{shared,private} functions to use the new
function. Opportunistically update the size parameter to use size_t instead
of u64.
Co-developed-by: Ackerley Tng <ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-40-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Introduce a new helper, kvm_gpa_to_guest_memfd(), to find the
guest_memfd-related details of a memory region that contains a given guest
physical address (GPA).
The function returns the file descriptor for the memfd, the offset into
the file that corresponds to the GPA, and the number of bytes remaining
in the region from that GPA.
kvm_gpa_to_guest_memfd() was factored out from vm_guest_mem_fallocate();
refactor vm_guest_mem_fallocate() to use the new helper.
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-39-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add helper functions to allow KVM selftests to pin memory using
CONFIG_GUP_TEST. This is useful for creating test scenarios where some page
has an increased refcount, such as when testing guest_memfd in-place
conversion.
The helpers open /sys/kernel/debug/gup_test and invoke the
PIN_LONGTERM_TEST_START and PIN_LONGTERM_TEST_STOP ioctls. Since this
functionality depends on the kernel being built with CONFIG_GUP_TEST,
provide stub implementations that trigger a test failure if the
configuration is missing.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-36-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add helper functions to kvm_util.h to support calling ioctls, specifically
KVM_SET_MEMORY_ATTRIBUTES2, on a guest_memfd file descriptor.
Introduce gmem_ioctl() and __gmem_ioctl() macros, modeled after the
existing vm_ioctl() helpers, to provide a standard way to call ioctls
on a guest_memfd.
Add gmem_set_memory_attributes() and its derivatives (gmem_set_private(),
gmem_set_shared()) to set memory attributes on a guest_memfd region.
Also provide "__" variants that return the ioctl error code instead of
aborting the test. These helpers will be used by upcoming guest_memfd
tests.
To avoid code duplication, factor out the check for supported memory
attributes into a new macro, TEST_ASSERT_SUPPORTED_ATTRIBUTES, and use
it in both the existing vm_set_memory_attributes() and the new
gmem_set_memory_attributes() helpers.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-28-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add a global variable, kvm_has_gmem_attributes, to make the result of
checking for KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES available to all tests.
kvm_has_gmem_attributes is true if guest_memfd tracks memory attributes, as
opposed to VM-level tracking.
This global variable is synced to the guest for testing convenience, to
avoid introducing subtle bugs when host/guest state is desynced.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-27-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Accept gmem_flags in vm_mem_add() to be able to create a guest_memfd within
vm_mem_add().
When vm_mem_add() is used to set up a guest_memfd for a memslot, set up the
provided (or created) gmem_fd as the fd for the user memory region. This
makes it available to be mmap()-ed from just like fds from other memory
sources.
For guest_memfds, mmap() using gmem_offset instead of 0 all the time.
Always use MAP_SHARED if mmap-ing from guest_memfd instead of reading flag
from the configured src_type, which doesn't include guest_memfd.
Add a kvm_slot_to_fd() helper to provide convenient access to the file
descriptor of a memslot.
Update existing callers of vm_mem_add() to pass 0 for gmem_flags to
preserve existing behavior.
Co-developed-by: Ackerley Tng <ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-26-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Rename local variables and function parameters for the guest memory file
descriptor and its offset to use a "gmem_" prefix instead of
"guest_memfd_".
No functional change intended.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Tested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://patch.msgid.link/20260910-gmem-inplace-conversion-v13-25-dd6fbf94f4e1@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
sea_to_user backs guest memory with 1GB hugepages but never checks that
any are reserved. On a host with an empty pool it aborts instead of
skipping:
kvm_syscalls.h:68: mem != MAP_FAILED, errno=12 (ENOMEM)
not ok 1 selftests: kvm: sea_to_user # exit=254
The mmap() of the hugetlb region fails with -ENOMEM because no 1GB pages
are available, and the test treats that as a hard failure even though it
simply cannot run without the backing pages. Check the free 1GB hugepage
count up front and skip cleanly when the host cannot satisfy the region.
Signed-off-by: Like Xu <likexu@tencent.com>
Reviewed-by: Jiaqi Yan <jiaqiyan@google.com>
Link: https://patch.msgid.link/20260818112920.26252-3-likexu@tencent.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Add a two-VPE VGICv5 LPI delivery test. LPIs depend on an IST whose
base is provided by the guest through IRS_IST_BASER, which causes KVM
to allocate and provide an LPI IST to the hardware. Exercise the
virtual IRS ID registers and IST base configuration path before
checking interrupt delivery.
Back the guest's LPI IST with a dedicated userspace memslot and
identity-map it into the guest at the same IPA and VA. This lets the
guest provide that address to the emulated IRS through IRS_IST_BASER
while the host test still allocates and owns the backing memory.
Have VPE0 enable the IRS, derive a valid linear LPI IST configuration
from the virtual IRS ID registers, provide the IST base through
IRS_IST_BASER, configure one LPI for each VPE, and send an LPI to
VPE1. While the BASER is valid, attempt to change its address and
verify that the write is ignored. VPE1 consumes the first LPI and
replies with a second, which VPE0 consumes before completing the test.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-48-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Add VGICv5 SPI delivery coverage through KVM_IRQ_LINE. SPIs are
configured through the virtual IRS and delivered through the GICv5 CPU
interface, so the test needs to exercise both the userspace injection
path and the guest-side IRS programming path.
Map the virtual IRS into the guest, enable the IRS, configure SPI
trigger mode and target VPE from the guest, and check delivery of a
default SPI and SPI 1023, the last SPI in the maximum configured
range. This also exercises VGIC initialization and the IRS selector
at KVM's upper bound. Verify that invalid SPI numbers are rejected,
that lowering an edge-triggered SPI after it is pending does not
recall it, and that level-sensitive SPIs are delivered.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-47-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Add coverage for the VGICv5 IRS_REGS attribute group. Migration needs
a userspace-visible view of the virtual IRS register state, but KVM
must expose only valid registers and reject state that cannot be
restored safely.
Verify that KVM_HAS_DEVICE_ATTR reports the IRS_REGS group before the
IRS base is configured, while register reads and writes are rejected
before VGIC initialisation. Once the VGIC is initialised, verify that
all exposed registers can be read and their values written back.
Check that bad offsets, incorrect alignment, and bad userspace
pointers are rejected. Also check ID register restore validation, idle
status register values, and IRS_IST_BASER restore handling.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-43-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Add coverage for the VGICv5 IRS address attribute. The address is the
base of the guest-visible MMIO region used to configure the virtual
IRS, so userspace must provide a valid base address before the VM can
run.
Verify that KVM reports the attribute, returns VGIC_ADDR_UNDEF before
it is configured, rejects misaligned and out-of-IPA-range addresses,
accepts a valid base, rejects a second base, and fails vCPU entry if
the VGIC is initialized without an IRS address.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-41-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
This selftest was added before the GICv5 IRS was supported in
KVM. Therefore, there was no address to set, and the specific UAPI
didn't even exist.
Now that the IRS is supported, and setting its address is mandatory
before VGIC resources are mapped, set the emulated IRS GPA before
initialising the VGIC. Running a GICv5 VM will fail if userspace has
not provided the IRS address before the first vCPU run.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-25-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Not all CPUs that support VMX necessarily support the "virtualize APIC
accesses" secondary processor-based VM-execution control. For example,
some Zhaoxin CPUs lack this feature. Add a capability check before
running the test to properly skip on unsupported hardware instead of
failing.
Carve out the guts of kvm_cpu_has_ept() into a generic helper and use said
helper to provide kvm_cpu_has_vmx_apic_access_virt().
Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com>
Link: https://patch.msgid.link/20260910115414.3015260-10-ewanhai-oc@zhaoxin.com
[sean: add a helper instead of copy+pasting kvm_cpu_has_ept()]
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
kvm_is_mediated_pmu_enabled() returns kvm_amd's enable_mediated_pmu
module parameter unless the host CPU is Intel. Zhaoxin CPUs implement
VMX-compatible virtualization and are handled by KVM's VMX backend, so
on Zhaoxin hosts the helper wrongly reports kvm_amd's parameter.
Gate the check on host_cpu_is_intel_compatible so that Zhaoxin CPUs,
like Intel CPUs, query kvm_intel's enable_mediated_pmu instead. This
does not change behavior on Intel, and AMD and other non-Intel-
compatible CPUs still fall back to kvm_amd's parameter.
Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com>
Link: https://patch.msgid.link/20260910115414.3015260-3-ewanhai-oc@zhaoxin.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add helpers to detect Zhaoxin CPUs using the "CentaurHauls" and
" Shanghai " vendor strings.
KVM handles Zhaoxin CPUs with its VMX backend. Add
host_cpu_is_intel_compatible for selftests that exercise behavior shared
by Intel and Zhaoxin CPUs, while retaining host_cpu_is_zhaoxin for
Zhaoxin-specific behavior.
Signed-off-by: Frank Zhu <frankzhu@zhaoxin.com>
Link: https://patch.msgid.link/20260910115414.3015260-2-ewanhai-oc@zhaoxin.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Extract and slightly adopt the xAPIC IPI test's logic for getting the mask
and number of usable memory NUMA nodes into a common helper. To allow for
friendlier behavior when the underlying kernel doesn't support NUMA, or the
test was run without sufficient permissions, zero out the mask and return
"zero nodes" if get_mempolicy() fails with ENOSYS or EPERM respectively.
I.e. allow tests to skip (sub)tests instead of throwing an assert.
Suggested-by: Shivank Garg <shivankg@amd.com>
Reviewed-by: Shivank Garg <shivankg@amd.com>
Link: https://patch.msgid.link/20260903001625.2792367-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Compute the node masks for the source (from) and destination (to) NUMA
nodes in the xAPIC IPI test instead of pre-filling an array of masks with
node per mask. Computing the mask on-demand is technically slower, but
doesn't require a large-ish on-stack array, and more importantly allows the
test to use a generic "get next NUMA node" API without having to commit all
of KVM selftests to using a large array of single-bit nodemasks.
Implement said API as a common KVM NUMA API so that it can be used by other
tests, e.g. in guest_memfd tests. Deliberately make @from "exclusive" as
the anticipated usage in KVM selftests is to select the next, *different*
node, i.e. so that users don't have to copy+paste code to assert that the
found node is different than the starting node. The obvious downside is
that implementing the exclusive logic forces callers to pass -1 instead of
0 when the goal is to find the first node in the mask, but that arguably
yields more intuitive code anyways.
From an overall test functionality/coverage perspective, no functional
change intended (the walking pattern of node migration should be unchanged).
Reviewed-by: Shivank Garg <shivankg@amd.com>
Link: https://patch.msgid.link/20260903001625.2792367-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add and use MAXNODE_FOR_MASK() to compute the "correct" maxnode value that
is passed to various NUMA-related syscalls, e.g. get_mempolicy(), mbind(),
migrate_pages(), etc. In quotes, because the kernel has an undocumented,
longstanding off-by-one bug that requires userspace to specify the number
of bits plus one, i.e. the max node plus two.
The kernel bug has been known since 2007[*]:
: And this is I think the reason why we can't change this now. I assume
: numactl allocates 1024 bits (0 to 1023) and passes 1025 to make sure all
: 1024 bits are processed. If we change it now, kernel will process 1025
: bits (0 to 1024) and overflow the allocated bitmask. If it happens to be
: at the border of mmaped vma, it's a segfault...
But unfortunately the manpages haven't yet been updated, e.g.
: The maxnode argument is the maximum node number in the bit mask plus one
Link: https://lore.kernel.org/all/63ccc890-fd57-118b-5997-e0259f507d28@suse.cz[*]
Reviewed-by: Shivank Garg <shivankg@amd.com>
Link: https://patch.msgid.link/20260903001625.2792367-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Rename vmreadz() => vmread() (and vmread() => __vmread()) and have it
assert success instead of returning garbage on failure. While the eVMCS
path avoids clobbering *value on failure, the VMREAD path unconditionally
stores tmp to *value, without ever zeroing tmp. I.e. if VMREAD did fail,
*value would be loaded with random stack data, not '0'.
An audit of the code confirms that nothing is actually relying on vmreadz()
to zero the result on failure, as all paths either check for a non-zero
value, propagate the result into vmwrite(), or guard the vmread() with a
pre-check that the field exists.
Opportunistically fix the bug in what is now __vmread(), so that the code
isn't consuming uninitialized stack data. Begrudgingly keep zeroing
value in vmread(), as gcc-15 at least isn't smart enough to figure out
that value won't be used uninitialized (though to be fair, strictly
speaking it isn't actually unreachable code).
Link: https://patch.msgid.link/20260904002423.3154436-18-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Assert that vmwrite() succeeds instead of forcing all callers to do the
same (or as is much more common, ignoring VM-Fail and likely letting the
test fail in weird ways), opportunistically provide a more verbose error
message on failure.
All usage of vmwrite() "guarantees" success, either because the field in
question is unconditionally emulated by KVM, by virtue of earlier support
checks, or by falling over (later in the test) if the VMWRITE fails.
Cc: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260904002423.3154436-17-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add __vmwrite() in anticipation of having vmwrite() assert success, and use
the "failure allowed" version in the common VMCS setup code, which is the
only code that wants to write fields that may or may not exist (although
arguably the code should check if the field exists instead of blindly
writing).
E.g. When doing initial configuration of a VMCS, the core library doesn't
want to assume secondary controls are supported, and so blindly does a
VMWRITE and pivots on success/failure.
All usage of vmwrite() outside of common setup already asserts success, or
100% relies on VMWRITE succeeding in order for the test to function
correctly.
No functional change intended.
Link: https://patch.msgid.link/20260904002423.3154436-16-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Assert success in the "outer" APIs for VMLAUNCH and VMRESUME to dedup a
pile of code, and switch to the double-underscores versions as necessary,
to make it more obvious which paths expect VM-Enter *failure*.
Link: https://patch.msgid.link/20260904002423.3154436-15-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Dedup the assembly code for VMLAUNCH vs. VMRESUME, for both architectural
VMCS and eVMCS, as the difference is literally only the actual VM-Enter
instruction for VMLAUNCH vs. VMRESUME, and VMWRITE vs. MOV for VMCS vs.
eVMCS.
Opportunistically place the implementations in vmx.c so that the lengthy
sequence (~580 bytes of code) aren't inlined for every single VM-Enter.
000000000041b910 <__vmlaunch>:
41b910: 80 3d 61 5e 10 00 00 cmpb $0x0,0x105e61(%rip) # 521778 <enable_evmcs>
41b917: 0f 85 13 01 00 00 jne 41ba30 <__vmlaunch+0x120>
41b91d: ba 14 6c 00 00 mov $0x6c14,%edx
41b922: b9 16 6c 00 00 mov $0x6c16,%ecx
41b927: 6a 00 push $0x0
41b929: 0f 79 d4 vmwrite %rsp,%rdx
41b92c: 48 8d 05 82 00 00 00 lea 0x82(%rip),%rax # 41b9b5 <__vmlaunch+0xa5>
41b933: 0f 79 c8 vmwrite %rax,%rcx
<xchg GPRs>
41b9ae: 0f 01 c2 vmlaunch
41b9b1: 48 ff 04 24 incq (%rsp)
<xchg GPRs>
41ba2d: 58 pop %rax
41ba2e: c3 ret
41ba2f: 90 nop
41ba30: 48 8b 35 39 5d 10 00 mov 0x105d39(%rip),%rsi # 521770 <current_evmcs>
41ba37: c7 86 38 03 00 00 00 00 00 00 movl $0x0,0x338(%rsi)
41ba41: 6a 00 push $0x0
41ba43: 48 89 a6 68 02 00 00 mov %rsp,0x268(%rsi)
41ba4a: 48 8d 05 83 00 00 00 lea 0x83(%rip),%rax # 41bad4 <__vmlaunch+0x1c4>
41ba51: 48 89 46 50 mov %rax,0x50(%rsi)
<xchg GPRs>
41bacd: 0f 01 c2 vmlaunch
41bad0: 48 ff 04 24 incq (%rsp)
<xchg GPRs>
41bb4c: 58 pop %rax
41bb4d: c3 ret
No functional change intended (though the code generation will be quite
different).
Cc: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260904002423.3154436-14-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop the return codes from evmcs_vmptrld() and load_evmcs() as they are
hardcoded to return '0' and "true" respectively.
No functional change intended.
Link: https://patch.msgid.link/20260904002423.3154436-13-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add macros to build helpers for VMXON, VMPTRLD, and VMCLEAR, i.e. the VMX
instructions that take a VMCS address as input, and don't have outputs.
Getting the params right is annoying, especially when using KVM_ASM_SAFE().
As a bonus, this adds non-asserting double-underscores versions of VMXON
and VMCLEAR for "free".
Link: https://patch.msgid.link/20260904002423.3154436-12-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Now that load_vmcs() either asserts or returns success, drop the return
code and the many asserts in its callers.
Link: https://patch.msgid.link/20260904002423.3154436-11-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Assert that vmptrld() succeeds instead of forcing all callers to do the
same, and opportunistically provide a macro to print (hopefully) useful
information on VMX instruction failures.
Leave load_vmcs() as-is for the moment to minimize the amount of churn
since the vmptrld() changes aren't completely trivial.
Link: https://patch.msgid.link/20260904002423.3154436-10-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Continue removing dead error "handling", and assert that VMCLEAR
succeeds instead of forcing callers of load_vmcs() to assert success.
For all intents and purposes, no functional change intended.
Link: https://patch.msgid.link/20260904002423.3154436-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
succeed
Assert that vmxon() succeeds, and by extension prepare_for_vmx_operation().
Forcing every caller to assert that a core preparation helper succeeds is
absurd and generates hard-to-read code.
For all intents and purposes, no functional change intended.
Link: https://patch.msgid.link/20260904002423.3154436-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Assert success in vmptrst() instead of punting to the caller, as literally
every user expects VMPTRST to succeed (and because '0' is a valid physical
address).
Link: https://patch.msgid.link/20260904002423.3154436-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Check that VMPTRLD when eVMCS is active results in #UD. This matches
genuine Hyper-V's behavior.
Use KVM_ASM_SAFE framework to handle #UD from VMPTRLD. Unfortunately, the
same trick cannot be applied to the existing #UD check on VMLAUNCH as
VMLAUNCH clobbers all registers which KVM_ASM_SAFE depends on. Keep
VMLAUNCH handling separately. Deliberately use a double-underscores
prefix instead of a "safe" postfix for the helper, to communicate that the
inner/outer helpers handle more than just exceptions, they also handle
VM-Fail conditions.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
[sean: use __ instead of _safe]
Link: https://patch.msgid.link/20260904002423.3154436-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Previously, VMPTRST was forbidden with eVMCS and selftests were mocking the
correct behavior in vmptrst() by returning enlightened vmptr directly.
Since KVM's behavior has changed to match genuine Hyper-V, adjust evmcs
test accordingly.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://patch.msgid.link/20260904002423.3154436-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Use a straight MOV instead of an XOR to zero R9 in the non-faulting path of
__KVM_ASM_SAFE() so as not to clobber RFLAGS. XOR generates smaller code,
but optimizing performance by minimizing the code footprint is just about
the last thing that KVM selftests care about.
The bug is relatively benign in the current code base, e.g. it marginally
degrades the coverage in the fastops test, but otherwise does no harm. But
the bug will become actively problematic if/when the "safe assembly" macros
are used for instructions that communicate results via RFLAGS, e.g. for VMX
instructions, which signal failure via RFLAGS.CF and RFLAGS.ZF.
Opportunistically use R9D instead of the full R9, as bits 63:32 of GPRs are
zeroed on writes to bit 31:0.
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260818165258.2613603-5-vkuznets@redhat.com
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://patch.msgid.link/20260904002423.3154436-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add an arch hook to communicate to the core physical page allocator that
page table allocations need to be naturally aligned. The hook will be used
for upcoming PowerPC support, which has MMU tables that are larger than the
guest base page size and need to be naturally aligned.
Bury the hook in the physical page allocator to avoid having to plumb a
rarely used param into the main APIs.
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Tested-by: Itaru Kitayam <itaru.kitayama@fujitsu.com>
Link: https://patch.msgid.link/20260902164123.2546762-21-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Automatically choose the minimum GPA for physical page allocations based on
the region type instead of sprinkling the logic over various wrappers and
tests. All usage falls into three categories: (a) don't care, just use the
bare minimum GPA, (b) page tables, use a slightly higher min to keep low
memory available, (c) custom memslot, use the base of the memslot. I.e.
there isn't a strong need to allow completely custom minimums.
Opportunistically move the vGIC LPI stress test's "gpa_base" variable into
setup_memslot() as the only reason it was a global variable was so that it
could be passed as the minimum GPA for allocations from the extra memslot.
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Itaru Kitayam <itaru.kitayama@fujitsu.com>
Link: https://patch.msgid.link/20260902164123.2546762-20-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
