All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Robert Hoo <robert.hu@linux.intel.com>
Cc: <seanjc@google.com>, <pbonzini@redhat.com>,
	<binbin.wu@linux.intel.com>, <kvm@vger.kernel.org>
Subject: Re: [PATCH v5 3/5] KVM: x86: Virtualize CR3.LAM_{U48,U57}
Date: Fri, 3 Mar 2023 14:21:10 +0800	[thread overview]
Message-ID: <ZAGR1qG2ehb8iXDL@gao-cwp> (raw)
In-Reply-To: <20230227084547.404871-4-robert.hu@linux.intel.com>

On Mon, Feb 27, 2023 at 04:45:45PM +0800, Robert Hoo wrote:
>LAM feature uses 2 high bits in CR3 (bit 62 for LAM_U48 and bit 61 for
>LAM_U57) to enable/config LAM feature for user mode addresses. The LAM
>masking is done before legacy canonical checks.
>
>To virtualize LAM CR3 bits usage, this patch:
>1. Don't reserve these 2 bits when LAM is enable on the vCPU. Previously
>when validate CR3, kvm uses kvm_vcpu_is_legal_gpa(), now define
>kvm_vcpu_is_valid_cr3() which is actually kvm_vcpu_is_legal_gpa()
>+ CR3.LAM bits validation. Substitutes kvm_vcpu_is_legal/illegal_gpa()
>with kvm_vcpu_is_valid_cr3() in call sites where is validating CR3 rather
>than pure GPA.
>2. mmu::get_guest_pgd(), its implementation is get_cr3() which returns
>whole guest CR3 value. Strip LAM bits in those call sites that need pure
>PGD value, e.g. mmu_alloc_shadow_roots(), FNAME(walk_addr_generic)().
>3. When form a new guest CR3 (vmx_load_mmu_pgd()), melt in LAM bit
>(kvm_get_active_lam()).
>4. When guest sets CR3, identify ONLY-LAM-bits-toggling cases, where it is
>unnecessary to make new pgd, but just make request of load pgd, then new
>CR3.LAM bits configuration will be melt in (above point 3). To be
>conservative, this case still do TLB flush.

>5. For nested VM entry, allow the 2 CR3 bits set in corresponding
>VMCS host/guest fields.

isn't this already covered by item #1 above?

>
>Signed-off-by: Robert Hoo <robert.hu@linux.intel.com>
>---
> arch/x86/kvm/mmu.h             |  5 +++++
> arch/x86/kvm/mmu/mmu.c         |  9 ++++++++-
> arch/x86/kvm/mmu/paging_tmpl.h |  2 +-
> arch/x86/kvm/vmx/nested.c      |  4 ++--
> arch/x86/kvm/vmx/vmx.c         |  3 ++-
> arch/x86/kvm/x86.c             | 33 ++++++++++++++++++++++++++++-----
> arch/x86/kvm/x86.h             |  1 +
> 7 files changed, 47 insertions(+), 10 deletions(-)
>
>diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
>index 6bdaacb6faa0..866f2b7cb509 100644
>--- a/arch/x86/kvm/mmu.h
>+++ b/arch/x86/kvm/mmu.h
>@@ -142,6 +142,11 @@ static inline unsigned long kvm_get_active_pcid(struct kvm_vcpu *vcpu)
> 	return kvm_get_pcid(vcpu, kvm_read_cr3(vcpu));
> }
> 
>+static inline u64 kvm_get_active_lam(struct kvm_vcpu *vcpu)
>+{
>+	return kvm_read_cr3(vcpu) & (X86_CR3_LAM_U48 | X86_CR3_LAM_U57);
>+}

I think it is better to define a mask (like reserved_gpa_bits):

kvm_vcpu_arch {
	...

	/*
	 * Bits in CR3 used to enable certain features. These bits don't
	 * participate in page table walking. They should be masked to
	 * get the base address of page table. When shadow paging is
	 * used, these bits should be kept as is in the shadow CR3.
	 */
	u64 cr3_control_bits;

and initialize the mask in kvm_vcpu_after_set_cpuid():

	if (guest_cpuid_has(X86_FEATURE_LAM))
		vcpu->arch.cr3_control_bits = X86_CR3_LAM_U48 | X86_CR3_LAM_U57;

then add helpers to extract/mask control bits.

It is cleaner and can avoid looking up guest CPUID at runtime. And if
AMD has a similar feature (e.g., some CR3 bits are used as control bits),
it is easy to support that feature.

  reply	other threads:[~2023-03-03  6:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27  8:45 [PATCH v5 0/5] Linear Address Masking (LAM) KVM Enabling Robert Hoo
2023-02-27  8:45 ` [PATCH v5 1/5] KVM: x86: Virtualize CR4.LAM_SUP Robert Hoo
2023-03-02  7:17   ` Chao Gao
2023-03-02 12:03     ` Binbin Wu
2023-03-02 13:00     ` Robert Hoo
2023-02-27  8:45 ` [PATCH v5 2/5] [Trivial]KVM: x86: Explicitly cast ulong to bool in kvm_set_cr3() Robert Hoo
2023-03-02  7:24   ` Chao Gao
2023-03-03  3:23     ` Robert Hoo
2023-03-10 20:22       ` Sean Christopherson
2023-03-20 12:05         ` Binbin Wu
2023-03-20 13:56           ` Binbin Wu
2023-03-21 16:03             ` Sean Christopherson
2023-02-27  8:45 ` [PATCH v5 3/5] KVM: x86: Virtualize CR3.LAM_{U48,U57} Robert Hoo
2023-03-03  6:21   ` Chao Gao [this message]
2023-03-03 14:23     ` Robert Hoo
2023-03-03 15:53       ` Chao Gao
2023-03-05  1:31         ` Robert Hoo
2023-03-10 20:12   ` Sean Christopherson
2023-03-20  6:57     ` Binbin Wu
2023-02-27  8:45 ` [PATCH v5 4/5] KVM: x86: emulation: Apply LAM mask when emulating data access in 64-bit mode Robert Hoo
2023-03-02  6:41   ` Binbin Wu
2023-03-02 13:16     ` Robert Hoo
2023-03-03  1:08       ` Binbin Wu
2023-03-03  3:16         ` Robert Hoo
2023-03-03  3:35           ` Binbin Wu
2023-03-03  9:00             ` Robert Hoo
2023-03-03 10:18               ` Binbin Wu
2023-03-10 20:26         ` Sean Christopherson
2023-03-02  8:55   ` Chao Gao
2023-03-02 11:31     ` Binbin Wu
2023-03-10 20:23   ` Sean Christopherson
2023-02-27  8:45 ` [PATCH v5 5/5] KVM: x86: LAM: Expose LAM CPUID to user space VMM Robert Hoo
2023-03-03  6:46   ` Chao Gao

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=ZAGR1qG2ehb8iXDL@gao-cwp \
    --to=chao.gao@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@linux.intel.com \
    --cc=seanjc@google.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.