mbox series

[0/4] KVM: x86/mmu: Memtype related cleanups

Message ID 20220715230016.3762909-1-seanjc@google.com (mailing list archive)
Headers show
Series KVM: x86/mmu: Memtype related cleanups | expand

Message

Sean Christopherson July 15, 2022, 11 p.m. UTC
Minor cleanups for KVM's handling of the memtype that's shoved into SPTEs.

Patch 1 enforces that entry '0' of the host's IA32_PAT is configured for WB
memtype.  KVM subtle relies on this behavior (silently shoves '0' into the
SPTE PAT field).  Check this at KVM load time so that if that doesn't hold
true, KVM will refuse to load instead of running the guest with weird and
potentially dangerous memtypes.

Patch 2 is a pure code cleanup (ordered after patch 1 in case someone wants
to backport the PAT check).

Patch 3 add a mask to track whether or not KVM may use a non-zero memtype
value in SPTEs.  Essentially, it's a "is EPT enabled" flag without being an
explicit "is EPT enabled" flag.  This avoid some minor work when not using
EPT, e.g. technically KVM could drop the RET0 implemention that's used for
SVM's get_mt_mask(), but IMO that's an unnecessary risk.

Patch 4 modifies the TDP page fault path to restrict the mapping level
based on guest MTRRs if and only if KVM might actually consume them.  The
guest MTRRs are purely software constructs (not directly consumed by
hardware), and KVM only honors them when EPT is enabled (host MTRRs are
overridden by EPT) and the guest has non-coherent DMA.  I doubt this will
move the needed on whether or not KVM can create huge pages, but it does
save having to do MTRR lookups on every page fault for guests without
a non-coherent DMA device attached.

Sean Christopherson (4):
  KVM: x86: Reject loading KVM if host.PAT[0] != WB
  KVM: x86: Drop unnecessary goto+label in kvm_arch_init()
  KVM: x86/mmu: Add shadow mask for effective host MTRR memtype
  KVM: x86/mmu: Restrict mapping level based on guest MTRR iff they're
    used

 arch/x86/kvm/mmu/mmu.c  | 26 +++++++++++++++++++-------
 arch/x86/kvm/mmu/spte.c | 21 ++++++++++++++++++---
 arch/x86/kvm/mmu/spte.h |  1 +
 arch/x86/kvm/x86.c      | 33 ++++++++++++++++++++-------------
 4 files changed, 58 insertions(+), 23 deletions(-)


base-commit: 8031d87aa9953ddeb047a5356ebd0b240c30f233

Comments

Paolo Bonzini July 19, 2022, 5:59 p.m. UTC | #1
On 7/16/22 01:00, Sean Christopherson wrote:
> Minor cleanups for KVM's handling of the memtype that's shoved into SPTEs.
> 
> Patch 1 enforces that entry '0' of the host's IA32_PAT is configured for WB
> memtype.  KVM subtle relies on this behavior (silently shoves '0' into the
> SPTE PAT field).  Check this at KVM load time so that if that doesn't hold
> true, KVM will refuse to load instead of running the guest with weird and
> potentially dangerous memtypes.
> 
> Patch 2 is a pure code cleanup (ordered after patch 1 in case someone wants
> to backport the PAT check).
> 
> Patch 3 add a mask to track whether or not KVM may use a non-zero memtype
> value in SPTEs.  Essentially, it's a "is EPT enabled" flag without being an
> explicit "is EPT enabled" flag.  This avoid some minor work when not using
> EPT, e.g. technically KVM could drop the RET0 implemention that's used for
> SVM's get_mt_mask(), but IMO that's an unnecessary risk.
> 
> Patch 4 modifies the TDP page fault path to restrict the mapping level
> based on guest MTRRs if and only if KVM might actually consume them.  The
> guest MTRRs are purely software constructs (not directly consumed by
> hardware), and KVM only honors them when EPT is enabled (host MTRRs are
> overridden by EPT) and the guest has non-coherent DMA.  I doubt this will
> move the needed on whether or not KVM can create huge pages, but it does
> save having to do MTRR lookups on every page fault for guests without
> a non-coherent DMA device attached.
> 
> Sean Christopherson (4):
>    KVM: x86: Reject loading KVM if host.PAT[0] != WB
>    KVM: x86: Drop unnecessary goto+label in kvm_arch_init()
>    KVM: x86/mmu: Add shadow mask for effective host MTRR memtype
>    KVM: x86/mmu: Restrict mapping level based on guest MTRR iff they're
>      used
> 
>   arch/x86/kvm/mmu/mmu.c  | 26 +++++++++++++++++++-------
>   arch/x86/kvm/mmu/spte.c | 21 ++++++++++++++++++---
>   arch/x86/kvm/mmu/spte.h |  1 +
>   arch/x86/kvm/x86.c      | 33 ++++++++++++++++++++-------------
>   4 files changed, 58 insertions(+), 23 deletions(-)
> 
> 
> base-commit: 8031d87aa9953ddeb047a5356ebd0b240c30f233

Queued, thanks.

Paolo