- 11 Apr, 2023 4 commits
-
-
Sean Christopherson authored
Take the XFeature mask in __vm_xsave_require_permission() instead of the bit so that there's no need to define macros for both the bit and the mask. Asserting that only a single bit is set and retrieving said bit is easy enough via log2 helpers. Opportunistically clean up the error message for the ARCH_REQ_XCOMP_GUEST_PERM sanity check. Reviewed-by:
Aaron Lewis <aaronlewis@google.com> Tested-by:
Sean Christopherson <seanjc@google.com>
-
Aaron Lewis authored
The instructions XGETBV and XSETBV are useful to other tests. Move them to processor.h to make them more broadly available. No functional change intended. Reviewed-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
Mingwei Zhang <mizhang@google.com> [sean: reword shortlog] Reviewed-by:
-
Sean Christopherson authored
Filter out XTILE_CFG from the supported XCR0 reported to userspace if the current process doesn't have access to XTILE_DATA. Attempting to set XTILE_CFG in XCR0 will #GP if XTILE_DATA is also not set, and so keeping XTILE_CFG as supported results in explosions if userspace feeds KVM_GET_SUPPORTED_CPUID back into KVM and the guest doesn't sanity check CPUID. Fixes: 445ecdf7 ("kvm: x86: Exclude unpermitted xfeatures at KVM_GET_SUPPORTED_CPUID") Reported-by:
-
Aaron Lewis authored
Add a helper, kvm_get_filtered_xcr0(), to dedup code that needs to account for XCR0 features that require explicit opt-in on a per-process basis. In addition to documenting when KVM should/shouldn't consult xstate_get_guest_group_perm(), the helper will also allow sanitizing the filtered XCR0 to avoid enumerating architecturally illegal XCR0 values, e.g. XTILE_CFG without XTILE_DATA. No functional changes intended. Signed-off-by:
-
- 06 Apr, 2023 1 commit
-
-
Hao Ge authored
Close the "current_clocksource" file descriptor before returning or exiting from stable_tsc_check_supported() in vmx_nested_tsc_scaling_test. Signed-off-by:
Hao Ge <gehao@kylinos.cn> Reviewed-by:
Vipin Sharma <vipinsh@google.com> Link: https://lore.kernel.org/r/20230405101350.259000-1-gehao@kylinos.cnSigned-off-by:
-
- 24 Mar, 2023 16 commits
-
-
Aaron Lewis authored
Check that XTILEDATA supports XFD. In amx_test, add the requirement that the guest allows the xfeature, XTILEDATA, to be set in XFD. Otherwise, the test may fail. Signed-off-by:
-
Aaron Lewis authored
Check that the palette table exists before using it. The maximum number of AMX palette tables is enumerated by CPUID.1DH:EAX. Assert that the palette used in amx_test, CPUID.1DH.1H, does not exceed that maximum. Signed-off-by:
-
Aaron Lewis authored
Move the checks on XSAVE and OSXSAVE into init_regs() so that the XSAVE check is done before setting CR4.OSXSAVE, i.e. before a potential #GP, and so that the OSXSAVE check is performend immediately after enabling XSAVE in CR4. Signed-off-by:
-
Aaron Lewis authored
Assert that both XTILE{CFG,DATA} are written and read back via XSETBV and XGETBV respectively. The original check in amx_test only ensures at least one of the XTILE bits are set, XTILECFG or XTILEDATA, when it really should be checking that both are set. Fixes: bf70636d ("selftest: kvm: Add amx selftest") Signed-off-by: -
Aaron Lewis authored
Assert that XTILE is XSAVE-enabled. check_xsave_supports_xtile() doesn't actually check anything since its return value is not used. Add the intended assert. Opportunistically, move the assert to a more appropriate location: immediately after XSETBV and remove check_xsave_supports_xtile(). Fixes: 5dc19f1c ("KVM: selftests: Convert AMX test to use X86_PROPRETY_XXX") Signed-off-by:
-
Mingwei Zhang authored
Add asserts to verify the XSTATE metadata for XTILE_DATA isn't affected by disabling AMX tile data via IA32_XFD. XFD doesn't intercept XSAVE, it only prevents setting bits in XCR0, i.e. regardless of XFD, AMX state is managed by XSAVE/XRSTOR as long as the corresponding bits are set XCR0. Signed-off-by:
-
Mingwei Zhang authored
Add an extra check to IA32_XFD to ensure that XTILE_DATA is actually set, i.e. is consistent with the AMX architecture. In addition, repeat the checks after the guest/host world switch to ensure the values of IA32_XFD and IA32_XFD_ERR are well preserved. Signed-off-by:
-
Mingwei Zhang authored
Be extra paranoid and assert that CR0.TS is clear when verifying the #NM in the AMX test is due to the expected XFeature Disable error, i.e. that the #NM isn't due to CR0.TS=1. Signed-off-by:
-
Mingwei Zhang authored
After tilerelease instruction, AMX tiles are in INIT state. According to Intel SDM vol 1. 13.10: "If RFBM[i] = 1, XSTATE_BV[i] is set to the value of XINUSE[i].", XSTATE_BV[18] should be cleared after xsavec. On the other hand, according to Intel SDM vol 1. 13.4.3: "If XCOMP_BV[i] = 1, state component i is located at a byte offset locationI from the base address of the XSAVE area". Since at the time of xsavec, XCR0[18] is set indicating AMX tile data component is still enabled, xcomp_bv[18] should be set. Complete the checks by adding the assert to xcomp_bv[18] after xsavec. Signed-off-by:
-
Mingwei Zhang authored
After the execution of __tilerelease(), AMX component will be in INIT state. Therefore, execution of XSAVEC saving the AMX state into memory will cause the xstate_bv[18] cleared in xheader. However, the xcomp_bv[18] will remain set. Fix the error in comment. Also, update xsavec() to XSAVEC because xcomp_bv[18] is set due to the instruction, not the function. Finally, use XTILEDATA instead 'bit 18' in comments. Cc: Jim Mattson <jmattson@google.com> Cc: Venkatesh Srinivas <venkateshs@google.com> Cc: Aaron Lewis <aaronlewis@google.com> Signed-off-by:
-
Mingwei Zhang authored
Add a working xstate data structure for the usage of AMX and potential future usage on other xstate components. AMX selftest requires checking both the xstate_bv and xcomp_bv. Existing code relies on pointer arithmetics to fetch xstate_bv and does not support xcomp_bv. So, add a working xstate data structure into processor.h for x86. Suggested-by:
-
Ivan Orlov authored
There is a 'malloc' call in vcpu_save_state function, which can be unsuccessful. This patch will add the malloc failure checking to avoid possible null dereference and give more information about test fail reasons. Signed-off-by:
Ivan Orlov <ivan.orlov0322@gmail.com> Link: https://lore.kernel.org/r/20230322144528.704077-1-ivan.orlov0322@gmail.comSigned-off-by:
-
Ackerley Tng authored
Align the guest stack to match calling sequence requirements in section "The Stack Frame" of the System V ABI AMD64 Architecture Processor Supplement, which requires the value (%rsp + 8), NOT %rsp, to be a multiple of 16 when control is transferred to the function entry point. I.e. in a normal function call, %rsp needs to be 16-byte aligned _before_ CALL, not after. This fixes unexpected #GPs in guest code when the compiler uses SSE instructions, e.g. to initialize memory, as many SSE instructions require memory operands (including those on the stack) to be 16-byte-aligned. Signed-off-by:
Ackerley Tng <ackerleytng@google.com> Link: https://lore.kernel.org/r/20230227180601.104318-1-ackerleytng@google.comSigned-off-by:
-
Like Xu authored
Running x86_64/pmu_event_filter_test or x86_64/vmx_pmu_caps_test with enable_pmu globally disabled will report the following into: 1..0 # SKIP - Requirement not met: use_intel_pmu() || use_amd_pmu() or 1..0 # SKIP - Requirement not met: kvm_cpu_has(X86_FEATURE_PDCM) this can be confusing, so add a check on kvm.enable_pmu. Signed-off-by:
Like Xu <likexu@tencent.com> Link: https://lore.kernel.org/r/20230313085311.25327-3-likexu@tencent.comSigned-off-by:
-
Like Xu authored
Add a helper function for reading kvm boolean module parameters values. No functional change intended. Signed-off-by:
-
Anish Moorthy authored
demand_paging_test uses 1E8 as the denominator to convert nanoseconds to seconds, which is wrong. Use NSEC_PER_SEC instead to fix the issue and make the conversion obvious. Reported-by:
James Houghton <jthoughton@google.com> Signed-off-by:
Anish Moorthy <amoorthy@google.com> Reviewed-by:
Oliver Upton <oliver.upton@linux.dev> Reviewed-by:
-
- 16 Mar, 2023 9 commits
-
-
Thomas Huth authored
All kvm_arch_vm_ioctl() implementations now only deal with "int" types as return values, so we can change the return type of these functions to use "int" instead of "long". Signed-off-by:
Thomas Huth <thuth@redhat.com> Acked-by:
Anup Patel <anup@brainfault.org> Message-Id: <20230208140105.655814-7-thuth@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Thomas Huth authored
KVM functions use "long" return values for functions that are wired up to "struct file_operations", but otherwise use "int" return values for functions that can return 0/-errno in order to avoid unintentional divergences between 32-bit and 64-bit kernels. Some code still uses "long" in unnecessary spots, though, which can cause a little bit of confusion and unnecessary size casts. Let's change these spots to use "int" types, too. Signed-off-by:
-
Thomas Huth authored
In case of success, this function returns the amount of handled bytes. However, this does not work for large values: The function is called from kvm_arch_vm_ioctl() (which still returns a long), which in turn is called from kvm_vm_ioctl() in virt/kvm/kvm_main.c. And that function stores the return value in an "int r" variable. So the upper 32-bits of the "long" return value are lost there. KVM ioctl functions should only return "int" values, so let's limit the amount of bytes that can be requested here to INT_MAX to avoid the problem with the truncated return value. We can then also change the return type of the function to "int" to make it clearer that it is not possible to return a "long" here. Fixes: f0376edb ("KVM: arm64: Add ioctl to fetch/store tags in a guest") Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Gavin Shan <gshan@redhat.com> Reviewed-by:
Steven Price <steven.price@arm.com> Message-Id: <20230208140105.655814-5-thuth@redhat.com> Signed-off-by:
-
Thomas Huth authored
The KVM_GET_NR_MMU_PAGES ioctl is quite questionable on 64-bit hosts since it fails to return the full 64 bits of the value that can be set with the corresponding KVM_SET_NR_MMU_PAGES call. Its "long" return value is truncated into an "int" in the kvm_arch_vm_ioctl() function. Since this ioctl also never has been used by userspace applications (QEMU, Google's internal VMM, kvmtool and CrosVM have been checked), it's likely the best if we remove this badly designed ioctl before anybody really tries to use it. Signed-off-by:
-
Thomas Huth authored
These two functions only return normal integers, so it does not make sense to declare the return type as "long" here. Reviewed-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by:
-
Thomas Huth authored
Most functions that are related to kvm_arch_vm_ioctl() already use "int" as return type to pass error values back to the caller. Some outlier functions use "long" instead for no good reason (they do not really require long values here). Let's standardize on "int" here to avoid casting the values back and forth between the two types. Reviewed-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Emanuele Giuseppe Esposito authored
FLUSH_L1D was already added in 11e34e64, but the feature is not visible to userspace yet. The bit definition: CPUID.(EAX=7,ECX=0):EDX[bit 28] If the feature is supported by the host, kvm should support it too so that userspace can choose whether to expose it to the guest or not. One disadvantage of not exposing it is that the guest will report a non existing vulnerability in /sys/devices/system/cpu/vulnerabilities/mmio_stale_data because the mitigation is present only if the guest supports (FLUSH_L1D and MD_CLEAR) or FB_CLEAR. Signed-off-by:
Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20230201132905.549148-4-eesposit@redhat.com> Signed-off-by:
-
Emanuele Giuseppe Esposito authored
Expose IA32_FLUSH_CMD to the guest if the guest CPUID enumerates support for this MSR. As with IA32_PRED_CMD, permission for unintercepted writes to this MSR will be granted to the guest after the first non-zero write. Signed-off-by:
-
Emanuele Giuseppe Esposito authored
Expose IA32_FLUSH_CMD to the guest if the guest CPUID enumerates support for this MSR. As with IA32_PRED_CMD, permission for unintercepted writes to this MSR will be granted to the guest after the first non-zero write. Co-developed-by:
-
- 14 Mar, 2023 10 commits
-
-
Sean Christopherson authored
Rename enable_evmcs to __kvm_is_using_evmcs to match its wrapper, and to avoid confusion with enabling eVMCS for nested virtualization, i.e. have "enable eVMCS" be reserved for "enable eVMCS support for L1". No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Wrap enable_evmcs in a helper and stub it out when CONFIG_HYPERV=n in order to eliminate the static branch nop placeholders. clang-14 is clever enough to elide the nop, but gcc-12 is not. Stubbing out the key reduces the size of kvm-intel.ko by ~7.5% (200KiB) when compiled with gcc-12 (there are a _lot_ of VMCS accesses throughout KVM). Reviewed-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Sean Christopherson authored
Move the macros that define the set of VMCS controls that are supported by eVMCS1 from hyperv.h to hyperv.c, i.e. make them "private". The macros should never be consumed directly by KVM at-large since the "final" set of supported controls depends on guest CPUID. No functional change intended. Reviewed-by:
-
Lai Jiangshan authored
Drop FNAME(is_self_change_mapping) and instead rely on kvm_mmu_hugepage_adjust() to adjust the hugepage accordingly. Prior to commit 4cd071d1 ("KVM: x86/mmu: Move calls to thp_adjust() down a level"), the hugepage adjustment was done before allocating new shadow pages, i.e. failed to restrict the hugepage sizes if a new shadow page resulted in account_shadowed() changing the disallowed hugepage tracking. Removing FNAME(is_self_change_mapping) fixes a bug reported by Huang Hang where KVM unnecessarily forces a 4KiB page. FNAME(is_self_change_mapping) has a defect in that it blindly disables _all_ hugepage mappings rather than trying to reduce the size of the hugepage. If the guest is writing to a 1GiB page and the 1GiB is self-referential but a 2MiB page is not, then KVM can and should create a 2MiB mapping. Add a comment above the call to kvm_mmu_hugepage_adjust() to call out the new dependency on adjusting the hugepage size after walking indirect PTEs. Reported-by:
Huang Hang <hhuang@linux.alibaba.com> Signed-off-by:
Lai Jiangshan <jiangshan.ljs@antgroup.com> Link: https://lore.kernel.org/r/20221213125538.81209-1-jiangshanlai@gmail.com [sean: rework changelog after separating out the emulator change] Signed-off-by:
-
Lai Jiangshan authored
Move the detection of write #PF to shadow pages, i.e. a fault on a write to a page table that is being shadowed by KVM that is used to translate the write itself, from FNAME(is_self_change_mapping) to FNAME(fetch). There is no need to detect the self-referential write before kvm_faultin_pfn() as KVM does not consume EMULTYPE_WRITE_PF_TO_SP for accesses that resolve to "error or no-slot" pfns, i.e. KVM doesn't allow retrying MMIO accesses or writes to read-only memslots. Detecting the EMULTYPE_WRITE_PF_TO_SP scenario in FNAME(fetch) will allow dropping FNAME(is_self_change_mapping) entirely, as the hugepage interaction can be deferred to kvm_mmu_hugepage_adjust(). Cc: Huang Hang <hhuang@linux.alibaba.com> Signed-off-by:
-
Sean Christopherson authored
Use a new EMULTYPE flag, EMULTYPE_WRITE_PF_TO_SP, to track page faults on self-changing writes to shadowed page tables instead of propagating that information to the emulator via a semi-persistent vCPU flag. Using a flag in "struct kvm_vcpu_arch" is confusing, especially as implemented, as it's not at all obvious that clearing the flag only when emulation actually occurs is correct. E.g. if KVM sets the flag and then retries the fault without ever getting to the emulator, the flag will be left set for future calls into the emulator. But because the flag is consumed if and only if both EMULTYPE_PF and EMULTYPE_ALLOW_RETRY_PF are set, and because EMULTYPE_ALLOW_RETRY_PF is deliberately not set for direct MMUs, emulated MMIO, or while L2 is active, KVM avoids false positives on a stale flag since FNAME(page_fault) is guaranteed to be run and refresh the flag before it's ultimately consumed by the tail end of reexecute_instruction(). Signed-off-by:
-
Vipin Sharma authored
Add missing KVM_EXIT_* reasons in KVM selftests from include/uapi/linux/kvm.h Signed-off-by:
-
Sean Christopherson authored
Add and use a macro to generate the KVM exit reason strings array instead of relying on developers to correctly copy+paste+edit each string. Signed-off-by:
-
Vipin Sharma authored
Print what KVM exit reason a test was expecting and what it actually got int TEST_ASSERT_KVM_EXIT_REASON(). Signed-off-by:
-
Vipin Sharma authored
Make TEST_ASSERT_KVM_EXIT_REASON() macro and replace all exit reason test assert statements with it. No functional changes intended. Signed-off-by:
David Matlack <dmatlack@google.com> Message-Id: <20230204014547.583711-2-vipinsh@google.com> Signed-off-by:
-
