The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] KVM: x86/mmu: Memtype related cleanups
Date: Fri, 15 Jul 2022 23:00:12 +0000	[thread overview]
Message-ID: <20220715230016.3762909-1-seanjc@google.com> (raw)

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
-- 
2.37.0.170.g444d1eabd0-goog


             reply	other threads:[~2022-07-15 23:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 23:00 Sean Christopherson [this message]
2022-07-15 23:00 ` [PATCH 1/4] KVM: x86: Reject loading KVM if host.PAT[0] != WB Sean Christopherson
2022-07-15 23:06   ` Jim Mattson
2022-07-15 23:18     ` Sean Christopherson
2022-07-18  9:42       ` Maxim Levitsky
2022-07-15 23:00 ` [PATCH 2/4] KVM: x86: Drop unnecessary goto+label in kvm_arch_init() Sean Christopherson
2022-07-18 10:03   ` Maxim Levitsky
2022-07-18 15:10     ` Sean Christopherson
2022-07-15 23:00 ` [PATCH 3/4] KVM: x86/mmu: Add shadow mask for effective host MTRR memtype Sean Christopherson
2022-07-18 12:08   ` Maxim Levitsky
2022-07-18 16:07     ` Sean Christopherson
2022-07-15 23:00 ` [PATCH 4/4] KVM: x86/mmu: Restrict mapping level based on guest MTRR iff they're used Sean Christopherson
2022-07-18 12:08   ` Maxim Levitsky
2022-07-19 17:59 ` [PATCH 0/4] KVM: x86/mmu: Memtype related cleanups Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220715230016.3762909-1-seanjc@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox