2020-10-16 17:29:37 +03:00
// SPDX-License-Identifier: GPL-2.0-only
/*
* Kernel - based Virtual Machine driver for Linux
*
* Macros and functions to access KVM PTEs ( also known as SPTEs )
*
* Copyright ( C ) 2006 Qumranet , Inc .
* Copyright 2020 Red Hat , Inc . and / or its affiliates .
*/
# include <linux/kvm_host.h>
# include "mmu.h"
# include "mmu_internal.h"
# include "x86.h"
# include "spte.h"
# include <asm/e820/api.h>
2021-12-15 19:56:11 +03:00
# include <asm/memtype.h>
2021-02-25 23:47:42 +03:00
# include <asm/vmx.h>
2020-10-16 17:29:37 +03:00
2022-04-20 03:27:47 +03:00
bool __read_mostly enable_mmio_caching = true ;
2022-08-04 01:49:56 +03:00
static bool __ro_after_init allow_mmio_caching ;
2021-02-25 23:47:36 +03:00
module_param_named ( mmio_caching , enable_mmio_caching , bool , 0444 ) ;
2021-02-25 23:47:43 +03:00
u64 __read_mostly shadow_host_writable_mask ;
u64 __read_mostly shadow_mmu_writable_mask ;
2020-10-16 17:29:37 +03:00
u64 __read_mostly shadow_nx_mask ;
u64 __read_mostly shadow_x_mask ; /* mutual exclusive with nx_mask */
u64 __read_mostly shadow_user_mask ;
u64 __read_mostly shadow_accessed_mask ;
u64 __read_mostly shadow_dirty_mask ;
u64 __read_mostly shadow_mmio_value ;
2021-02-25 23:47:35 +03:00
u64 __read_mostly shadow_mmio_mask ;
2020-10-16 17:29:37 +03:00
u64 __read_mostly shadow_mmio_access_mask ;
u64 __read_mostly shadow_present_mask ;
2022-07-16 02:00:15 +03:00
u64 __read_mostly shadow_memtype_mask ;
KVM: x86/mmu: Add shadow_me_value and repurpose shadow_me_mask
Intel Multi-Key Total Memory Encryption (MKTME) repurposes couple of
high bits of physical address bits as 'KeyID' bits. Intel Trust Domain
Extentions (TDX) further steals part of MKTME KeyID bits as TDX private
KeyID bits. TDX private KeyID bits cannot be set in any mapping in the
host kernel since they can only be accessed by software running inside a
new CPU isolated mode. And unlike to AMD's SME, host kernel doesn't set
any legacy MKTME KeyID bits to any mapping either. Therefore, it's not
legitimate for KVM to set any KeyID bits in SPTE which maps guest
memory.
KVM maintains shadow_zero_check bits to represent which bits must be
zero for SPTE which maps guest memory. MKTME KeyID bits should be set
to shadow_zero_check. Currently, shadow_me_mask is used by AMD to set
the sme_me_mask to SPTE, and shadow_me_shadow is excluded from
shadow_zero_check. So initializing shadow_me_mask to represent all
MKTME keyID bits doesn't work for VMX (as oppositely, they must be set
to shadow_zero_check).
Introduce a new 'shadow_me_value' to replace existing shadow_me_mask,
and repurpose shadow_me_mask as 'all possible memory encryption bits'.
The new schematic of them will be:
- shadow_me_value: the memory encryption bit(s) that will be set to the
SPTE (the original shadow_me_mask).
- shadow_me_mask: all possible memory encryption bits (which is a super
set of shadow_me_value).
- For now, shadow_me_value is supposed to be set by SVM and VMX
respectively, and it is a constant during KVM's life time. This
perhaps doesn't fit MKTME but for now host kernel doesn't support it
(and perhaps will never do).
- Bits in shadow_me_mask are set to shadow_zero_check, except the bits
in shadow_me_value.
Introduce a new helper kvm_mmu_set_me_spte_mask() to initialize them.
Replace shadow_me_mask with shadow_me_value in almost all code paths,
except the one in PT64_PERM_MASK, which is used by need_remote_flush()
to determine whether remote TLB flush is needed. This should still use
shadow_me_mask as any encryption bit change should need a TLB flush.
And for AMD, move initializing shadow_me_value/shadow_me_mask from
kvm_mmu_reset_all_pte_masks() to svm_hardware_setup().
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <f90964b93a3398b1cf1c56f510f3281e0709e2ab.1650363789.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-19 14:17:03 +03:00
u64 __read_mostly shadow_me_value ;
2020-10-16 17:29:37 +03:00
u64 __read_mostly shadow_me_mask ;
u64 __read_mostly shadow_acc_track_mask ;
u64 __read_mostly shadow_nonpresent_or_rsvd_mask ;
u64 __read_mostly shadow_nonpresent_or_rsvd_lower_gfn_mask ;
u8 __read_mostly shadow_phys_bits ;
2022-08-04 01:49:56 +03:00
void __init kvm_mmu_spte_module_init ( void )
{
/*
* Snapshot userspace ' s desire to allow MMIO caching . Whether or not
* KVM can actually enable MMIO caching depends on vendor - specific
* hardware capabilities and other module params that can ' t be resolved
* until the vendor module is loaded , i . e . enable_mmio_caching can and
* will change when the vendor module is ( re ) loaded .
*/
allow_mmio_caching = enable_mmio_caching ;
}
2020-10-16 17:29:37 +03:00
static u64 generation_mmio_spte_mask ( u64 gen )
{
u64 mask ;
WARN_ON ( gen & ~ MMIO_SPTE_GEN_MASK ) ;
2020-12-05 03:48:08 +03:00
mask = ( gen < < MMIO_SPTE_GEN_LOW_SHIFT ) & MMIO_SPTE_GEN_LOW_MASK ;
mask | = ( gen < < MMIO_SPTE_GEN_HIGH_SHIFT ) & MMIO_SPTE_GEN_HIGH_MASK ;
2020-10-16 17:29:37 +03:00
return mask ;
}
u64 make_mmio_spte ( struct kvm_vcpu * vcpu , u64 gfn , unsigned int access )
{
u64 gen = kvm_vcpu_memslots ( vcpu ) - > generation & MMIO_SPTE_GEN_MASK ;
2021-02-25 23:47:34 +03:00
u64 spte = generation_mmio_spte_mask ( gen ) ;
2020-10-16 17:29:37 +03:00
u64 gpa = gfn < < PAGE_SHIFT ;
2021-02-25 23:47:31 +03:00
WARN_ON_ONCE ( ! shadow_mmio_value ) ;
2020-10-16 17:29:37 +03:00
access & = shadow_mmio_access_mask ;
2021-02-25 23:47:34 +03:00
spte | = shadow_mmio_value | access ;
spte | = gpa | shadow_nonpresent_or_rsvd_mask ;
spte | = ( gpa & shadow_nonpresent_or_rsvd_mask )
2020-10-30 20:39:55 +03:00
< < SHADOW_NONPRESENT_OR_RSVD_MASK_LEN ;
2020-10-16 17:29:37 +03:00
2021-02-25 23:47:34 +03:00
return spte ;
2020-10-16 17:29:37 +03:00
}
static bool kvm_is_mmio_pfn ( kvm_pfn_t pfn )
{
if ( pfn_valid ( pfn ) )
return ! is_zero_pfn ( pfn ) & & PageReserved ( pfn_to_page ( pfn ) ) & &
/*
* Some reserved pages , such as those from NVDIMM
* DAX devices , are not for MMIO , and can be mapped
* with cached memory type for better performance .
* However , the above check misconceives those pages
* as MMIO , and results in KVM mapping them with UC
* memory type , which would hurt the performance .
* Therefore , we check the host memory type in addition
* and only treat UC / UC - / WC pages as MMIO .
*/
( ! pat_enabled ( ) | | pat_pfn_immune_to_uc_mtrr ( pfn ) ) ;
return ! e820__mapped_raw_any ( pfn_to_hpa ( pfn ) ,
pfn_to_hpa ( pfn + 1 ) - 1 ,
E820_TYPE_RAM ) ;
}
KVM: x86/mmu: Move shadow-present check out of spte_has_volatile_bits()
Move the is_shadow_present_pte() check out of spte_has_volatile_bits()
and into its callers. Well, caller, since only one of its two callers
doesn't already do the shadow-present check.
Opportunistically move the helper to spte.c/h so that it can be used by
the TDP MMU, which is also the primary motivation for the shadow-present
change. Unlike the legacy MMU, the TDP MMU uses a single path for clear
leaf and non-leaf SPTEs, and to avoid unnecessary atomic updates, the TDP
MMU will need to check is_last_spte() prior to calling
spte_has_volatile_bits(), and calling is_last_spte() without first
calling is_shadow_present_spte() is at best odd, and at worst a violation
of KVM's loosely defines SPTE rules.
Note, mmu_spte_clear_track_bits() could likely skip the write entirely
for SPTEs that are not shadow-present. Leave that cleanup for a future
patch to avoid introducing a functional change, and because the
shadow-present check can likely be moved further up the stack, e.g.
drop_large_spte() appears to be the only path that doesn't already
explicitly check for a shadow-present SPTE.
No functional change intended.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220423034752.1161007-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-23 06:47:42 +03:00
/*
* Returns true if the SPTE has bits that may be set without holding mmu_lock .
* The caller is responsible for checking if the SPTE is shadow - present , and
* for determining whether or not the caller cares about non - leaf SPTEs .
*/
bool spte_has_volatile_bits ( u64 spte )
{
/*
* Always atomically update spte if it can be updated
* out of mmu - lock , it can ensure dirty bit is not lost ,
* also , it can help us to get a stable is_writable_pte ( )
* to ensure tlb flush is not missed .
*/
if ( ! is_writable_pte ( spte ) & & is_mmu_writable_spte ( spte ) )
return true ;
if ( is_access_track_spte ( spte ) )
return true ;
if ( spte_ad_enabled ( spte ) ) {
if ( ! ( spte & shadow_accessed_mask ) | |
( is_writable_pte ( spte ) & & ! ( spte & shadow_dirty_mask ) ) )
return true ;
}
return false ;
}
2021-08-17 14:43:19 +03:00
bool make_spte ( struct kvm_vcpu * vcpu , struct kvm_mmu_page * sp ,
2021-11-16 02:45:58 +03:00
const struct kvm_memory_slot * slot ,
2021-08-17 14:43:19 +03:00
unsigned int pte_access , gfn_t gfn , kvm_pfn_t pfn ,
2021-09-29 16:19:32 +03:00
u64 old_spte , bool prefetch , bool can_unsync ,
2021-08-17 14:43:19 +03:00
bool host_writable , u64 * new_spte )
2020-10-16 17:29:37 +03:00
{
2021-08-17 14:43:19 +03:00
int level = sp - > role . level ;
2021-02-25 23:47:45 +03:00
u64 spte = SPTE_MMU_PRESENT_MASK ;
2021-08-17 14:32:09 +03:00
bool wrprot = false ;
2020-10-16 17:29:37 +03:00
KVM: x86/mmu: Drop RWX=0 SPTEs during ept_sync_page()
All of sync_page()'s existing checks filter out only !PRESENT gPTE,
because without execute-only, all upper levels are guaranteed to be at
least READABLE. However, if EPT with execute-only support is in use by
L1, KVM can create an SPTE that is shadow-present but guest-inaccessible
(RWX=0) if the upper level combined permissions are R (or RW) and
the leaf EPTE is changed from R (or RW) to X. Because the EPTE is
considered present when viewed in isolation, and no reserved bits are set,
FNAME(prefetch_invalid_gpte) will consider the GPTE valid, and cause a
not-present SPTE to be created.
The SPTE is "correct": the guest translation is inaccessible because
the combined protections of all levels yield RWX=0, and KVM will just
redirect any vmexits to the guest. If EPT A/D bits are disabled, KVM
can mistake the SPTE for an access-tracked SPTE, but again such confusion
isn't fatal, as the "saved" protections are also RWX=0. However,
creating a useless SPTE in general means that KVM messed up something,
even if this particular goof didn't manifest as a functional bug.
So, drop SPTEs whose new protections will yield a RWX=0 SPTE, and
add a WARN in make_spte() to detect creation of SPTEs that will
result in RWX=0 protections.
Fixes: d95c55687e11 ("kvm: mmu: track read permission explicitly for shadow EPT page tables")
Cc: David Matlack <dmatlack@google.com>
Cc: Ben Gardon <bgardon@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220513195000.99371-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-13 22:49:59 +03:00
WARN_ON_ONCE ( ! pte_access & & ! shadow_present_mask ) ;
2021-08-17 14:43:19 +03:00
if ( sp - > role . ad_disabled )
2021-02-25 23:47:37 +03:00
spte | = SPTE_TDP_AD_DISABLED_MASK ;
2021-11-18 05:08:42 +03:00
else if ( kvm_mmu_page_ad_need_write_protect ( sp ) )
2021-02-25 23:47:37 +03:00
spte | = SPTE_TDP_AD_WRPROT_ONLY_MASK ;
2020-10-16 17:29:37 +03:00
/*
* For the EPT case , shadow_present_mask is 0 if hardware
* supports exec - only page table entries . In that case ,
* ACC_USER_MASK and shadow_user_mask are used to represent
* read access . See FNAME ( gpte_access ) in paging_tmpl . h .
*/
spte | = shadow_present_mask ;
2021-09-29 16:19:32 +03:00
if ( ! prefetch )
2020-10-16 17:29:37 +03:00
spte | = spte_shadow_accessed_mask ( spte ) ;
if ( level > PG_LEVEL_4K & & ( pte_access & ACC_EXEC_MASK ) & &
2022-06-14 00:25:21 +03:00
is_nx_huge_page_enabled ( vcpu - > kvm ) ) {
2020-10-16 17:29:37 +03:00
pte_access & = ~ ACC_EXEC_MASK ;
}
if ( pte_access & ACC_EXEC_MASK )
spte | = shadow_x_mask ;
else
spte | = shadow_nx_mask ;
if ( pte_access & ACC_USER_MASK )
spte | = shadow_user_mask ;
if ( level > PG_LEVEL_4K )
spte | = PT_PAGE_SIZE_MASK ;
2022-07-16 02:00:15 +03:00
if ( shadow_memtype_mask )
spte | = static_call ( kvm_x86_get_mt_mask ) ( vcpu , gfn ,
kvm_is_mmio_pfn ( pfn ) ) ;
2020-10-16 17:29:37 +03:00
if ( host_writable )
2021-02-25 23:47:43 +03:00
spte | = shadow_host_writable_mask ;
2020-10-16 17:29:37 +03:00
else
pte_access & = ~ ACC_WRITE_MASK ;
KVM: x86/mmu: Add shadow_me_value and repurpose shadow_me_mask
Intel Multi-Key Total Memory Encryption (MKTME) repurposes couple of
high bits of physical address bits as 'KeyID' bits. Intel Trust Domain
Extentions (TDX) further steals part of MKTME KeyID bits as TDX private
KeyID bits. TDX private KeyID bits cannot be set in any mapping in the
host kernel since they can only be accessed by software running inside a
new CPU isolated mode. And unlike to AMD's SME, host kernel doesn't set
any legacy MKTME KeyID bits to any mapping either. Therefore, it's not
legitimate for KVM to set any KeyID bits in SPTE which maps guest
memory.
KVM maintains shadow_zero_check bits to represent which bits must be
zero for SPTE which maps guest memory. MKTME KeyID bits should be set
to shadow_zero_check. Currently, shadow_me_mask is used by AMD to set
the sme_me_mask to SPTE, and shadow_me_shadow is excluded from
shadow_zero_check. So initializing shadow_me_mask to represent all
MKTME keyID bits doesn't work for VMX (as oppositely, they must be set
to shadow_zero_check).
Introduce a new 'shadow_me_value' to replace existing shadow_me_mask,
and repurpose shadow_me_mask as 'all possible memory encryption bits'.
The new schematic of them will be:
- shadow_me_value: the memory encryption bit(s) that will be set to the
SPTE (the original shadow_me_mask).
- shadow_me_mask: all possible memory encryption bits (which is a super
set of shadow_me_value).
- For now, shadow_me_value is supposed to be set by SVM and VMX
respectively, and it is a constant during KVM's life time. This
perhaps doesn't fit MKTME but for now host kernel doesn't support it
(and perhaps will never do).
- Bits in shadow_me_mask are set to shadow_zero_check, except the bits
in shadow_me_value.
Introduce a new helper kvm_mmu_set_me_spte_mask() to initialize them.
Replace shadow_me_mask with shadow_me_value in almost all code paths,
except the one in PT64_PERM_MASK, which is used by need_remote_flush()
to determine whether remote TLB flush is needed. This should still use
shadow_me_mask as any encryption bit change should need a TLB flush.
And for AMD, move initializing shadow_me_value/shadow_me_mask from
kvm_mmu_reset_all_pte_masks() to svm_hardware_setup().
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <f90964b93a3398b1cf1c56f510f3281e0709e2ab.1650363789.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-19 14:17:03 +03:00
if ( shadow_me_value & & ! kvm_is_mmio_pfn ( pfn ) )
spte | = shadow_me_value ;
2020-10-16 17:29:37 +03:00
spte | = ( u64 ) pfn < < PAGE_SHIFT ;
if ( pte_access & ACC_WRITE_MASK ) {
2021-02-25 23:47:43 +03:00
spte | = PT_WRITABLE_MASK | shadow_mmu_writable_mask ;
2020-10-16 17:29:37 +03:00
/*
* Optimization : for pte sync , if spte was writable the hash
* lookup is unnecessary ( and expensive ) . Write protection
2021-06-22 20:56:58 +03:00
* is responsibility of kvm_mmu_get_page / kvm_mmu_sync_roots .
2020-10-16 17:29:37 +03:00
* Same reasoning can be applied to dirty page accounting .
*/
2021-09-18 03:56:36 +03:00
if ( is_writable_pte ( old_spte ) )
2020-10-16 17:29:37 +03:00
goto out ;
2021-06-22 20:56:58 +03:00
/*
* Unsync shadow pages that are reachable by the new , writable
* SPTE . Write - protect the SPTE if the page can ' t be unsync ' d ,
* e . g . it ' s write - tracked ( upper - level SPs ) or has one or more
* shadow pages and unsync ' ing pages is not allowed .
*/
2021-11-16 02:45:54 +03:00
if ( mmu_try_to_unsync_pages ( vcpu - > kvm , slot , gfn , can_unsync , prefetch ) ) {
2020-10-16 17:29:37 +03:00
pgprintk ( " %s: found shadow page for %llx, marking ro \n " ,
__func__ , gfn ) ;
2021-08-17 14:32:09 +03:00
wrprot = true ;
2020-10-16 17:29:37 +03:00
pte_access & = ~ ACC_WRITE_MASK ;
2021-02-25 23:47:43 +03:00
spte & = ~ ( PT_WRITABLE_MASK | shadow_mmu_writable_mask ) ;
2020-10-16 17:29:37 +03:00
}
}
if ( pte_access & ACC_WRITE_MASK )
spte | = spte_shadow_dirty_mask ( spte ) ;
2021-09-18 03:56:36 +03:00
out :
2021-09-29 16:19:32 +03:00
if ( prefetch )
2020-10-16 17:29:37 +03:00
spte = mark_spte_for_access_track ( spte ) ;
2021-06-22 20:57:33 +03:00
WARN_ONCE ( is_rsvd_spte ( & vcpu - > arch . mmu - > shadow_zero_check , spte , level ) ,
" spte = 0x%llx, level = %d, rsvd bits = 0x%llx " , spte , level ,
get_rsvd_bits ( & vcpu - > arch . mmu - > shadow_zero_check , spte , level ) ) ;
2021-08-17 15:46:45 +03:00
if ( ( spte & PT_WRITABLE_MASK ) & & kvm_slot_dirty_track_enabled ( slot ) ) {
/* Enforced by kvm_mmu_hugepage_adjust. */
WARN_ON ( level > PG_LEVEL_4K ) ;
mark_page_dirty_in_slot ( vcpu - > kvm , slot , gfn ) ;
}
2021-09-24 11:52:23 +03:00
2020-10-16 17:29:37 +03:00
* new_spte = spte ;
2021-08-17 14:32:09 +03:00
return wrprot ;
2020-10-16 17:29:37 +03:00
}
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
static u64 make_spte_executable ( u64 spte )
{
bool is_access_track = is_access_track_spte ( spte ) ;
if ( is_access_track )
spte = restore_acc_track_spte ( spte ) ;
spte & = ~ shadow_nx_mask ;
spte | = shadow_x_mask ;
if ( is_access_track )
spte = mark_spte_for_access_track ( spte ) ;
return spte ;
}
/*
* Construct an SPTE that maps a sub - page of the given huge page SPTE where
* ` index ` identifies which sub - page .
*
* This is used during huge page splitting to build the SPTEs that make up the
* new page table .
*/
2022-06-22 22:27:05 +03:00
u64 make_huge_page_split_spte ( struct kvm * kvm , u64 huge_spte , union kvm_mmu_page_role role ,
2022-06-14 00:25:21 +03:00
int index )
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
{
u64 child_spte ;
if ( WARN_ON_ONCE ( ! is_shadow_present_pte ( huge_spte ) ) )
return 0 ;
if ( WARN_ON_ONCE ( ! is_large_pte ( huge_spte ) ) )
return 0 ;
child_spte = huge_spte ;
/*
* The child_spte already has the base address of the huge page being
* split . So we just have to OR in the offset to the page at the next
* lower level for the given index .
*/
2022-06-22 22:27:05 +03:00
child_spte | = ( index * KVM_PAGES_PER_HPAGE ( role . level ) ) < < PAGE_SHIFT ;
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
2022-06-22 22:27:05 +03:00
if ( role . level = = PG_LEVEL_4K ) {
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
child_spte & = ~ PT_PAGE_SIZE_MASK ;
/*
2022-06-22 22:27:05 +03:00
* When splitting to a 4 K page where execution is allowed , mark
* the page executable as the NX hugepage mitigation no longer
* applies .
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
*/
2022-06-22 22:27:05 +03:00
if ( ( role . access & ACC_EXEC_MASK ) & & is_nx_huge_page_enabled ( kvm ) )
KVM: x86/mmu: Split huge pages mapped by the TDP MMU when dirty logging is enabled
When dirty logging is enabled without initially-all-set, try to split
all huge pages in the memslot down to 4KB pages so that vCPUs do not
have to take expensive write-protection faults to split huge pages.
Eager page splitting is best-effort only. This commit only adds the
support for the TDP MMU, and even there splitting may fail due to out
of memory conditions. Failures to split a huge page is fine from a
correctness standpoint because KVM will always follow up splitting by
write-protecting any remaining huge pages.
Eager page splitting moves the cost of splitting huge pages off of the
vCPU threads and onto the thread enabling dirty logging on the memslot.
This is useful because:
1. Splitting on the vCPU thread interrupts vCPUs execution and is
disruptive to customers whereas splitting on VM ioctl threads can
run in parallel with vCPU execution.
2. Splitting all huge pages at once is more efficient because it does
not require performing VM-exit handling or walking the page table for
every 4KiB page in the memslot, and greatly reduces the amount of
contention on the mmu_lock.
For example, when running dirty_log_perf_test with 96 virtual CPUs, 1GiB
per vCPU, and 1GiB HugeTLB memory, the time it takes vCPUs to write to
all of their memory after dirty logging is enabled decreased by 95% from
2.94s to 0.14s.
Eager Page Splitting is over 100x more efficient than the current
implementation of splitting on fault under the read lock. For example,
taking the same workload as above, Eager Page Splitting reduced the CPU
required to split all huge pages from ~270 CPU-seconds ((2.94s - 0.14s)
* 96 vCPU threads) to only 1.55 CPU-seconds.
Eager page splitting does increase the amount of time it takes to enable
dirty logging since it has split all huge pages. For example, the time
it took to enable dirty logging in the 96GiB region of the
aforementioned test increased from 0.001s to 1.55s.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220119230739.2234394-16-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-20 02:07:36 +03:00
child_spte = make_spte_executable ( child_spte ) ;
}
return child_spte ;
}
2020-10-16 17:29:37 +03:00
u64 make_nonleaf_spte ( u64 * child_pt , bool ad_disabled )
{
2021-02-25 23:47:45 +03:00
u64 spte = SPTE_MMU_PRESENT_MASK ;
2020-10-16 17:29:37 +03:00
2021-02-25 23:47:45 +03:00
spte | = __pa ( child_pt ) | shadow_present_mask | PT_WRITABLE_MASK |
KVM: x86/mmu: Add shadow_me_value and repurpose shadow_me_mask
Intel Multi-Key Total Memory Encryption (MKTME) repurposes couple of
high bits of physical address bits as 'KeyID' bits. Intel Trust Domain
Extentions (TDX) further steals part of MKTME KeyID bits as TDX private
KeyID bits. TDX private KeyID bits cannot be set in any mapping in the
host kernel since they can only be accessed by software running inside a
new CPU isolated mode. And unlike to AMD's SME, host kernel doesn't set
any legacy MKTME KeyID bits to any mapping either. Therefore, it's not
legitimate for KVM to set any KeyID bits in SPTE which maps guest
memory.
KVM maintains shadow_zero_check bits to represent which bits must be
zero for SPTE which maps guest memory. MKTME KeyID bits should be set
to shadow_zero_check. Currently, shadow_me_mask is used by AMD to set
the sme_me_mask to SPTE, and shadow_me_shadow is excluded from
shadow_zero_check. So initializing shadow_me_mask to represent all
MKTME keyID bits doesn't work for VMX (as oppositely, they must be set
to shadow_zero_check).
Introduce a new 'shadow_me_value' to replace existing shadow_me_mask,
and repurpose shadow_me_mask as 'all possible memory encryption bits'.
The new schematic of them will be:
- shadow_me_value: the memory encryption bit(s) that will be set to the
SPTE (the original shadow_me_mask).
- shadow_me_mask: all possible memory encryption bits (which is a super
set of shadow_me_value).
- For now, shadow_me_value is supposed to be set by SVM and VMX
respectively, and it is a constant during KVM's life time. This
perhaps doesn't fit MKTME but for now host kernel doesn't support it
(and perhaps will never do).
- Bits in shadow_me_mask are set to shadow_zero_check, except the bits
in shadow_me_value.
Introduce a new helper kvm_mmu_set_me_spte_mask() to initialize them.
Replace shadow_me_mask with shadow_me_value in almost all code paths,
except the one in PT64_PERM_MASK, which is used by need_remote_flush()
to determine whether remote TLB flush is needed. This should still use
shadow_me_mask as any encryption bit change should need a TLB flush.
And for AMD, move initializing shadow_me_value/shadow_me_mask from
kvm_mmu_reset_all_pte_masks() to svm_hardware_setup().
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <f90964b93a3398b1cf1c56f510f3281e0709e2ab.1650363789.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-19 14:17:03 +03:00
shadow_user_mask | shadow_x_mask | shadow_me_value ;
2020-10-16 17:29:37 +03:00
if ( ad_disabled )
2021-02-25 23:47:37 +03:00
spte | = SPTE_TDP_AD_DISABLED_MASK ;
2020-10-16 17:29:37 +03:00
else
spte | = shadow_accessed_mask ;
return spte ;
}
u64 kvm_mmu_changed_pte_notifier_make_spte ( u64 old_spte , kvm_pfn_t new_pfn )
{
u64 new_spte ;
2022-06-15 02:33:25 +03:00
new_spte = old_spte & ~ SPTE_BASE_ADDR_MASK ;
2020-10-16 17:29:37 +03:00
new_spte | = ( u64 ) new_pfn < < PAGE_SHIFT ;
new_spte & = ~ PT_WRITABLE_MASK ;
2021-02-25 23:47:43 +03:00
new_spte & = ~ shadow_host_writable_mask ;
2022-01-14 02:30:18 +03:00
new_spte & = ~ shadow_mmu_writable_mask ;
2020-10-16 17:29:37 +03:00
new_spte = mark_spte_for_access_track ( new_spte ) ;
return new_spte ;
}
u64 mark_spte_for_access_track ( u64 spte )
{
if ( spte_ad_enabled ( spte ) )
return spte & ~ shadow_accessed_mask ;
if ( is_access_track_spte ( spte ) )
return spte ;
2022-01-26 02:05:15 +03:00
check_spte_writable_invariants ( spte ) ;
2020-10-16 17:29:37 +03:00
2020-10-30 20:39:55 +03:00
WARN_ONCE ( spte & ( SHADOW_ACC_TRACK_SAVED_BITS_MASK < <
SHADOW_ACC_TRACK_SAVED_BITS_SHIFT ) ,
2020-10-16 17:29:37 +03:00
" kvm: Access Tracking saved bit locations are not zero \n " ) ;
2020-10-30 20:39:55 +03:00
spte | = ( spte & SHADOW_ACC_TRACK_SAVED_BITS_MASK ) < <
SHADOW_ACC_TRACK_SAVED_BITS_SHIFT ;
2020-10-16 17:29:37 +03:00
spte & = ~ shadow_acc_track_mask ;
return spte ;
}
2021-02-25 23:47:35 +03:00
void kvm_mmu_set_mmio_spte_mask ( u64 mmio_value , u64 mmio_mask , u64 access_mask )
2020-10-16 17:29:37 +03:00
{
BUG_ON ( ( u64 ) ( unsigned ) access_mask ! = access_mask ) ;
WARN_ON ( mmio_value & shadow_nonpresent_or_rsvd_lower_gfn_mask ) ;
2021-02-25 23:47:29 +03:00
2022-08-04 01:49:56 +03:00
/*
* Reset to the original module param value to honor userspace ' s desire
* to ( dis ) allow MMIO caching . Update the param itself so that
* userspace can see whether or not KVM is actually using MMIO caching .
*/
enable_mmio_caching = allow_mmio_caching ;
2021-02-25 23:47:36 +03:00
if ( ! enable_mmio_caching )
mmio_value = 0 ;
2021-02-25 23:47:29 +03:00
/*
* Disable MMIO caching if the MMIO value collides with the bits that
* are used to hold the relocated GFN when the L1TF mitigation is
* enabled . This should never fire as there is no known hardware that
* can trigger this condition , e . g . SME / SEV CPUs that require a custom
* MMIO value are not susceptible to L1TF .
*/
if ( WARN_ON ( mmio_value & ( shadow_nonpresent_or_rsvd_mask < <
SHADOW_NONPRESENT_OR_RSVD_MASK_LEN ) ) )
mmio_value = 0 ;
2021-02-25 23:47:48 +03:00
/*
* The masked MMIO value must obviously match itself and a removed SPTE
* must not get a false positive . Removed SPTEs and MMIO SPTEs should
* never collide as MMIO must set some RWX bits , and removed SPTEs must
* not set any RWX bits .
*/
if ( WARN_ON ( ( mmio_value & mmio_mask ) ! = mmio_value ) | |
WARN_ON ( mmio_value & & ( REMOVED_SPTE & mmio_mask ) = = mmio_value ) )
mmio_value = 0 ;
2022-04-20 03:27:47 +03:00
if ( ! mmio_value )
enable_mmio_caching = false ;
2021-02-25 23:47:35 +03:00
shadow_mmio_value = mmio_value ;
shadow_mmio_mask = mmio_mask ;
2020-10-16 17:29:37 +03:00
shadow_mmio_access_mask = access_mask ;
}
EXPORT_SYMBOL_GPL ( kvm_mmu_set_mmio_spte_mask ) ;
KVM: x86/mmu: Add shadow_me_value and repurpose shadow_me_mask
Intel Multi-Key Total Memory Encryption (MKTME) repurposes couple of
high bits of physical address bits as 'KeyID' bits. Intel Trust Domain
Extentions (TDX) further steals part of MKTME KeyID bits as TDX private
KeyID bits. TDX private KeyID bits cannot be set in any mapping in the
host kernel since they can only be accessed by software running inside a
new CPU isolated mode. And unlike to AMD's SME, host kernel doesn't set
any legacy MKTME KeyID bits to any mapping either. Therefore, it's not
legitimate for KVM to set any KeyID bits in SPTE which maps guest
memory.
KVM maintains shadow_zero_check bits to represent which bits must be
zero for SPTE which maps guest memory. MKTME KeyID bits should be set
to shadow_zero_check. Currently, shadow_me_mask is used by AMD to set
the sme_me_mask to SPTE, and shadow_me_shadow is excluded from
shadow_zero_check. So initializing shadow_me_mask to represent all
MKTME keyID bits doesn't work for VMX (as oppositely, they must be set
to shadow_zero_check).
Introduce a new 'shadow_me_value' to replace existing shadow_me_mask,
and repurpose shadow_me_mask as 'all possible memory encryption bits'.
The new schematic of them will be:
- shadow_me_value: the memory encryption bit(s) that will be set to the
SPTE (the original shadow_me_mask).
- shadow_me_mask: all possible memory encryption bits (which is a super
set of shadow_me_value).
- For now, shadow_me_value is supposed to be set by SVM and VMX
respectively, and it is a constant during KVM's life time. This
perhaps doesn't fit MKTME but for now host kernel doesn't support it
(and perhaps will never do).
- Bits in shadow_me_mask are set to shadow_zero_check, except the bits
in shadow_me_value.
Introduce a new helper kvm_mmu_set_me_spte_mask() to initialize them.
Replace shadow_me_mask with shadow_me_value in almost all code paths,
except the one in PT64_PERM_MASK, which is used by need_remote_flush()
to determine whether remote TLB flush is needed. This should still use
shadow_me_mask as any encryption bit change should need a TLB flush.
And for AMD, move initializing shadow_me_value/shadow_me_mask from
kvm_mmu_reset_all_pte_masks() to svm_hardware_setup().
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <f90964b93a3398b1cf1c56f510f3281e0709e2ab.1650363789.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-19 14:17:03 +03:00
void kvm_mmu_set_me_spte_mask ( u64 me_value , u64 me_mask )
{
/* shadow_me_value must be a subset of shadow_me_mask */
if ( WARN_ON ( me_value & ~ me_mask ) )
me_value = me_mask = 0 ;
shadow_me_value = me_value ;
shadow_me_mask = me_mask ;
}
EXPORT_SYMBOL_GPL ( kvm_mmu_set_me_spte_mask ) ;
2021-02-25 23:47:42 +03:00
void kvm_mmu_set_ept_masks ( bool has_ad_bits , bool has_exec_only )
2020-10-16 17:29:37 +03:00
{
2021-02-25 23:47:42 +03:00
shadow_user_mask = VMX_EPT_READABLE_MASK ;
shadow_accessed_mask = has_ad_bits ? VMX_EPT_ACCESS_BIT : 0ull ;
shadow_dirty_mask = has_ad_bits ? VMX_EPT_DIRTY_BIT : 0ull ;
shadow_nx_mask = 0ull ;
shadow_x_mask = VMX_EPT_EXECUTABLE_MASK ;
shadow_present_mask = has_exec_only ? 0ull : VMX_EPT_READABLE_MASK ;
2022-07-16 02:00:15 +03:00
/*
* EPT overrides the host MTRRs , and so KVM must program the desired
* memtype directly into the SPTEs . Note , this mask is just the mask
* of all bits that factor into the memtype , the actual memtype must be
* dynamically calculated , e . g . to ensure host MMIO is mapped UC .
*/
shadow_memtype_mask = VMX_EPT_MT_MASK | VMX_EPT_IPAT_BIT ;
2021-02-25 23:47:42 +03:00
shadow_acc_track_mask = VMX_EPT_RWX_MASK ;
2021-02-25 23:47:44 +03:00
shadow_host_writable_mask = EPT_SPTE_HOST_WRITABLE ;
shadow_mmu_writable_mask = EPT_SPTE_MMU_WRITABLE ;
2021-02-25 23:47:42 +03:00
/*
* EPT Misconfigurations are generated if the value of bits 2 : 0
* of an EPT paging - structure entry is 110 b ( write / execute ) .
*/
kvm_mmu_set_mmio_spte_mask ( VMX_EPT_MISCONFIG_WX_VALUE ,
VMX_EPT_RWX_MASK , 0 ) ;
2020-10-16 17:29:37 +03:00
}
2021-02-25 23:47:42 +03:00
EXPORT_SYMBOL_GPL ( kvm_mmu_set_ept_masks ) ;
2020-10-16 17:29:37 +03:00
void kvm_mmu_reset_all_pte_masks ( void )
{
u8 low_phys_bits ;
2021-02-25 23:47:41 +03:00
u64 mask ;
2020-10-16 17:29:37 +03:00
shadow_phys_bits = kvm_get_shadow_phys_bits ( ) ;
/*
* If the CPU has 46 or less physical address bits , then set an
* appropriate mask to guard against L1TF attacks . Otherwise , it is
* assumed that the CPU is not vulnerable to L1TF .
*
* Some Intel CPUs address the L1 cache using more PA bits than are
* reported by CPUID . Use the PA width of the L1 cache when possible
* to achieve more effective mitigation , e . g . if system RAM overlaps
* the most significant bits of legal physical address space .
*/
shadow_nonpresent_or_rsvd_mask = 0 ;
low_phys_bits = boot_cpu_data . x86_phys_bits ;
if ( boot_cpu_has_bug ( X86_BUG_L1TF ) & &
! WARN_ON_ONCE ( boot_cpu_data . x86_cache_bits > =
2020-10-30 20:39:55 +03:00
52 - SHADOW_NONPRESENT_OR_RSVD_MASK_LEN ) ) {
2020-10-16 17:29:37 +03:00
low_phys_bits = boot_cpu_data . x86_cache_bits
2020-10-30 20:39:55 +03:00
- SHADOW_NONPRESENT_OR_RSVD_MASK_LEN ;
2020-10-16 17:29:37 +03:00
shadow_nonpresent_or_rsvd_mask =
rsvd_bits ( low_phys_bits , boot_cpu_data . x86_cache_bits - 1 ) ;
}
shadow_nonpresent_or_rsvd_lower_gfn_mask =
GENMASK_ULL ( low_phys_bits - 1 , PAGE_SHIFT ) ;
2021-02-25 23:47:41 +03:00
2021-02-25 23:47:42 +03:00
shadow_user_mask = PT_USER_MASK ;
shadow_accessed_mask = PT_ACCESSED_MASK ;
shadow_dirty_mask = PT_DIRTY_MASK ;
shadow_nx_mask = PT64_NX_MASK ;
shadow_x_mask = 0 ;
shadow_present_mask = PT_PRESENT_MASK ;
2022-07-16 02:00:15 +03:00
/*
* For shadow paging and NPT , KVM uses PAT entry ' 0 ' to encode WB
* memtype in the SPTEs , i . e . relies on host MTRRs to provide the
* correct memtype ( WB is the " weakest " memtype ) .
*/
shadow_memtype_mask = 0 ;
2021-02-25 23:47:42 +03:00
shadow_acc_track_mask = 0 ;
KVM: x86/mmu: Add shadow_me_value and repurpose shadow_me_mask
Intel Multi-Key Total Memory Encryption (MKTME) repurposes couple of
high bits of physical address bits as 'KeyID' bits. Intel Trust Domain
Extentions (TDX) further steals part of MKTME KeyID bits as TDX private
KeyID bits. TDX private KeyID bits cannot be set in any mapping in the
host kernel since they can only be accessed by software running inside a
new CPU isolated mode. And unlike to AMD's SME, host kernel doesn't set
any legacy MKTME KeyID bits to any mapping either. Therefore, it's not
legitimate for KVM to set any KeyID bits in SPTE which maps guest
memory.
KVM maintains shadow_zero_check bits to represent which bits must be
zero for SPTE which maps guest memory. MKTME KeyID bits should be set
to shadow_zero_check. Currently, shadow_me_mask is used by AMD to set
the sme_me_mask to SPTE, and shadow_me_shadow is excluded from
shadow_zero_check. So initializing shadow_me_mask to represent all
MKTME keyID bits doesn't work for VMX (as oppositely, they must be set
to shadow_zero_check).
Introduce a new 'shadow_me_value' to replace existing shadow_me_mask,
and repurpose shadow_me_mask as 'all possible memory encryption bits'.
The new schematic of them will be:
- shadow_me_value: the memory encryption bit(s) that will be set to the
SPTE (the original shadow_me_mask).
- shadow_me_mask: all possible memory encryption bits (which is a super
set of shadow_me_value).
- For now, shadow_me_value is supposed to be set by SVM and VMX
respectively, and it is a constant during KVM's life time. This
perhaps doesn't fit MKTME but for now host kernel doesn't support it
(and perhaps will never do).
- Bits in shadow_me_mask are set to shadow_zero_check, except the bits
in shadow_me_value.
Introduce a new helper kvm_mmu_set_me_spte_mask() to initialize them.
Replace shadow_me_mask with shadow_me_value in almost all code paths,
except the one in PT64_PERM_MASK, which is used by need_remote_flush()
to determine whether remote TLB flush is needed. This should still use
shadow_me_mask as any encryption bit change should need a TLB flush.
And for AMD, move initializing shadow_me_value/shadow_me_mask from
kvm_mmu_reset_all_pte_masks() to svm_hardware_setup().
Signed-off-by: Kai Huang <kai.huang@intel.com>
Message-Id: <f90964b93a3398b1cf1c56f510f3281e0709e2ab.1650363789.git.kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-19 14:17:03 +03:00
shadow_me_mask = 0 ;
shadow_me_value = 0 ;
2021-02-25 23:47:42 +03:00
2022-01-26 02:07:13 +03:00
shadow_host_writable_mask = DEFAULT_SPTE_HOST_WRITABLE ;
shadow_mmu_writable_mask = DEFAULT_SPTE_MMU_WRITABLE ;
2021-02-25 23:47:43 +03:00
2021-02-25 23:47:41 +03:00
/*
* Set a reserved PA bit in MMIO SPTEs to generate page faults with
* PFEC . RSVD = 1 on MMIO accesses . 64 - bit PTEs ( PAE , x86 - 64 , and EPT
* paging ) support a maximum of 52 bits of PA , i . e . if the CPU supports
* 52 - bit physical addresses then there are no reserved PA bits in the
* PTEs and so the reserved PA approach must be disabled .
*/
if ( shadow_phys_bits < 52 )
mask = BIT_ULL ( 51 ) | PT_PRESENT_MASK ;
else
mask = 0 ;
kvm_mmu_set_mmio_spte_mask ( mask , mask , ACC_WRITE_MASK | ACC_USER_MASK ) ;
2020-10-16 17:29:37 +03:00
}