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
