From: Sean Christopherson <seanjc@google.com>
To: Yuan Yao <yuan.yao@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 5/9] KVM: x86/mmu: Free up A/D bits in FROZEN_SPTE
Date: Mon, 5 Aug 2024 15:17:20 -0700 [thread overview]
Message-ID: <ZrFPcJvYMpv8BH30@google.com> (raw)
In-Reply-To: <20240805072013.i3ib4h7eadlzzglm@yy-desk-7060>
On Mon, Aug 05, 2024, Yuan Yao wrote:
> On Thu, Aug 01, 2024 at 11:34:49AM -0700, Sean Christopherson wrote:
> > Remove all flavors of A/D bits from FROZEN_SPTE so that KVM can keep A/D
> > bits set in SPTEs that are frozen, without getting false positives.
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/kvm/mmu/spte.h | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
> > index ba7ff1dfbeb2..d403ecdfcb8e 100644
> > --- a/arch/x86/kvm/mmu/spte.h
> > +++ b/arch/x86/kvm/mmu/spte.h
> > @@ -216,15 +216,17 @@ extern u64 __read_mostly shadow_nonpresent_or_rsvd_mask;
> > * should not modify the SPTE.
> > *
> > * Use a semi-arbitrary value that doesn't set RWX bits, i.e. is not-present on
> > - * both AMD and Intel CPUs, and doesn't set PFN bits, i.e. doesn't create a L1TF
> > - * vulnerability.
> > + * both AMD and Intel CPUs, doesn't set any A/D bits, and doesn't set PFN bits,
> > + * i.e. doesn't create a L1TF vulnerability.
> > *
> > * Only used by the TDP MMU.
> > */
> > -#define FROZEN_SPTE (SHADOW_NONPRESENT_VALUE | 0x5a0ULL)
> > +#define FROZEN_SPTE (SHADOW_NONPRESENT_VALUE | 0x498ULL)
>
> Question:
> Why bit3 and bit4 also changed from 0 to 1 ?
Purely so that more bits are set, i.e. so that KVM doesn't rely on one or two
bits to identify frozen SPTEs.
> They're not part of AD bits fro EPT and CR3 page table/AMD NPT
This is very delibreate. The A/D bits need to be '0' in the FROZEN, i.e. bits
5,6, 8, and 9 must not be set in FROZEN_SPTE.
>
> EPT: Abit:8 Dbit:9
> CR3: Abit:5 Dbit:6
next prev parent reply other threads:[~2024-08-05 22:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 18:34 [RFC PATCH 0/9] KVM: x86/mmu: Preserve Accessed bits on PROT changes Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 1/9] KVM: x86/mmu: Add a dedicated flag to track if A/D bits are globally enabled Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 2/9] KVM: x86/mmu: Set shadow_accessed_mask for EPT even if A/D bits disabled Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 3/9] KVM: x86/mmu: Set shadow_dirty_mask " Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 4/9] KVM: x86/mmu: Use Accessed bit even when _hardware_ A/D bits are disabled Sean Christopherson
2024-08-05 16:49 ` David Matlack
2024-08-01 18:34 ` [RFC PATCH 5/9] KVM: x86/mmu: Free up A/D bits in FROZEN_SPTE Sean Christopherson
2024-08-05 7:20 ` Yuan Yao
2024-08-05 22:17 ` Sean Christopherson [this message]
2024-08-06 3:31 ` Yuan Yao
2024-08-01 18:34 ` [RFC PATCH 6/9] KVM: x86/mmu: Process only valid TDP MMU roots when aging a gfn range Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 7/9] KVM: x86/mmu: Stop processing TDP MMU roots for test_age if young SPTE found Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 8/9] KVM: Plumb mmu_notifier invalidation event type into arch code Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 9/9] KVM: x86/mmu: Track SPTE accessed info across mmu_notifier PROT changes Sean Christopherson
2024-08-05 7:59 ` Yuan Yao
2024-08-05 9:12 ` Yuan Yao
2024-08-07 6:41 ` Yuan Yao
2024-08-05 16:45 ` [RFC PATCH 0/9] KVM: x86/mmu: Preserve Accessed bits on " David Matlack
2024-08-05 20:11 ` Sean Christopherson
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=ZrFPcJvYMpv8BH30@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yuan.yao@linux.intel.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.