All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael Roth <michael.roth@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH 2/4] KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change
Date: Mon, 1 Aug 2022 23:20:25 +0000	[thread overview]
Message-ID: <YuhfuQbHy4P9EZcw@google.com> (raw)
In-Reply-To: <244f619a4e7a1c7079830d12379872a111da418d.camel@intel.com>

On Tue, Aug 02, 2022, Kai Huang wrote:
> On Mon, 2022-08-01 at 14:15 +0000, Sean Christopherson wrote:
> > Another thing to note is that only the value needs to be per-VM, the mask can be
> > KVM-wide, i.e. "mask = SUPPRESS_VE | RWX" will work for TDX and non-TDX VMs when
> > EPT is enabled.
> 
> Yeah, but is more like VMX and TDX both *happen* to have the same mask? 
> Theoretically,  VMX only need RWX to trigger EPT misconfiguration but doesn't
> need SUPPRESS_VE.

Right, SUPPRESS_VE isn't strictly necessary, but KVM already deliberately avoids
bit 63 because it has meaning, e.g. SUPPRESS_VE for EPT and NX for PAE and 64-bit
paging.  

> I don't see making mask/value both per-vm is a big issue?

Yes and no.

No, in the sense that it's not a big issue in terms of code.  

Yes, because of the connotations of having a per-VM mask.  While having SUPPRESS_VE
in the mask for non-TDX EPT isn't strictly necessary, it's also not strictly necessary
to _not_ have it in the mask.  In other words, having a per-VM mask incorrectly
implies that TDX _must_ have a different mask.

It's also one more piece of information that developers have to track down and
account for, i.e. one more thing we can screw up.

The other aspect of MMIO SPTEs are that the mask bits must not overlap the generation
bits or shadow-present bit, and changing any of those bits requires careful
consideration, i.e. defining the set of _allowed_ mask bits on a per-VM basis would
incur significant complexity without providing meaningful benefit.  As a result,
it's highly unlikely that we'll ever want to opportunsitically "reclaim" bit 63
for MMIO SPTEs, so there's practically zero cost if it's included in the mask for
non-TDX EPT.

  reply	other threads:[~2022-08-01 23:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28 22:17 [PATCH 0/4] KVM: x86/mmu: MMIO caching bug fixes Sean Christopherson
2022-07-28 22:17 ` [PATCH 1/4] KVM: x86: Tag kvm_mmu_x86_module_init() with __init Sean Christopherson
2022-07-29  2:14   ` Kai Huang
2022-07-28 22:17 ` [PATCH 2/4] KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change Sean Christopherson
2022-07-29  2:39   ` Kai Huang
2022-07-29 15:07     ` Sean Christopherson
2022-08-01  9:24       ` Kai Huang
2022-08-01 14:15         ` Sean Christopherson
2022-08-01 20:46           ` Kai Huang
2022-08-01 23:20             ` Sean Christopherson [this message]
2022-08-02  0:05               ` Kai Huang
2022-08-02 21:15                 ` Sean Christopherson
2022-08-02 22:19                   ` Kai Huang
2022-08-02 23:05                     ` Sean Christopherson
2022-08-02 23:42                       ` Kai Huang
2022-07-28 22:17 ` [PATCH 3/4] KVM: SVM: Adjust MMIO masks (for caching) before doing SEV(-ES) setup Sean Christopherson
2022-07-29  2:06   ` Kai Huang
2022-07-29 18:15     ` Sean Christopherson
2022-07-28 22:17 ` [PATCH 4/4] KVM: SVM: Disable SEV-ES support if MMIO caching is disable Sean Christopherson
2022-07-29  2:12   ` Kai Huang
2022-07-29 15:21     ` Sean Christopherson
2022-08-01  9:30       ` Kai Huang
2022-07-29  1:09 ` [PATCH 0/4] KVM: x86/mmu: MMIO caching bug fixes Michael Roth

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=YuhfuQbHy4P9EZcw@google.com \
    --to=seanjc@google.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=thomas.lendacky@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.