From: Sean Christopherson <seanjc@google.com>
To: Wei Huang <wei.huang2@amd.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com
Subject: Re: [PATCH v1 1/3] KVM: x86: Convert TDP level calculation to vendor's specific code
Date: Thu, 5 Aug 2021 21:51:42 +0000 [thread overview]
Message-ID: <YQxdbq+yoTIJmpL+@google.com> (raw)
In-Reply-To: <20210805205504.2647362-2-wei.huang2@amd.com>
On Thu, Aug 05, 2021, Wei Huang wrote:
> Currently the TDP level for x86 vCPU is calculated by checking both
> MAXPHYADDR and max_tdp_level. This design assumes that all x86 CPUs have
> the flexibility of changing the nested page table level different from host
> CPU. This assumption might not be true.
Heh, no need to be circumspect, just state that 5-level NPT inherits CR4.LA57
from the host. I didn't fully understand this sentence until I looked at patch 3.
> To solve this problem, let us
> create a kvm_x86_ops specific function for TDP level calculation.
>
> Signed-off-by: Wei Huang <wei.huang2@amd.com>
> ---
...
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 974cbfb1eefe..20ddfbac966e 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -723,7 +723,6 @@ struct kvm_vcpu_arch {
>
> u64 reserved_gpa_bits;
> int maxphyaddr;
> - int max_tdp_level;
Ha, this is leftover crud that can get zapped no matter what.
> /* emulate context */
>
...
> -static inline int kvm_mmu_get_tdp_level(struct kvm_vcpu *vcpu)
> -{
> - /* Use 5-level TDP if and only if it's useful/necessary. */
> - if (max_tdp_level == 5 && cpuid_maxphyaddr(vcpu) <= 48)
I'd strongly prefer to keep this logic in the MMU. When this was in vendor code,
there were multiple bugs where the MMU and VMX didn't communicate correctly, I
really don't want to back down that road.
Actually, I'm very, very tempted to say we should simply drop the cpuid_maxphyaddr()
bit and just return the max level (and I suppose rename it), e.g.
return mmu_tdp_level;
It's effectively a single 4kb page per VM, and Intel's numbers on 5-level paging
were that there was no measurable cost to the extra level. I would hope that
holds true here, too.
If we want to keep the MAXPHYADDR behavior, I'd vote for something like:
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index b4b65c21b2ca..7e35f2bf89b4 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -97,6 +97,7 @@ module_param_named(flush_on_reuse, force_flush_and_sync_on_reuse, bool, 0644);
bool tdp_enabled = false;
static int max_huge_page_level __read_mostly;
+static int tdp_root_level __read_mostly;
static int max_tdp_level __read_mostly;
enum {
@@ -4645,6 +4646,9 @@ static union kvm_mmu_role kvm_calc_mmu_role_common(struct kvm_vcpu *vcpu,
static inline int kvm_mmu_get_tdp_level(struct kvm_vcpu *vcpu)
{
+ if (tdp_root_level)
+ return tdp_root_level;
+
/* Use 5-level TDP if and only if it's useful/necessary. */
if (max_tdp_level == 5 && cpuid_maxphyaddr(vcpu) <= 48)
return 4;
@@ -5336,10 +5340,11 @@ void kvm_mmu_invpcid_gva(struct kvm_vcpu *vcpu, gva_t gva, unsigned long pcid)
*/
}
-void kvm_configure_mmu(bool enable_tdp, int tdp_max_root_level,
- int tdp_huge_page_level)
+void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
+ int tdp_max_root_level, int tdp_huge_page_level)
{
tdp_enabled = enable_tdp;
+ tdp_root_level = tdp_forced_root_level;
max_tdp_level = tdp_max_root_level;
/*
next prev parent reply other threads:[~2021-08-05 21:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 20:55 [PATCH v1 0/3] SVM 5-level page table support Wei Huang
2021-08-05 20:55 ` [PATCH v1 1/3] KVM: x86: Convert TDP level calculation to vendor's specific code Wei Huang
2021-08-05 21:51 ` Sean Christopherson [this message]
2021-08-05 22:26 ` Wei Huang
2021-08-08 19:30 ` Wei Huang
2021-08-05 22:35 ` Jim Mattson
2021-08-05 22:44 ` Sean Christopherson
2021-08-05 20:55 ` [PATCH v1 2/3] KVM: x86: Handle the case of 5-level shadow page table Wei Huang
2021-08-06 17:58 ` Sean Christopherson
2021-08-08 17:49 ` Wei Huang
2021-08-05 20:55 ` [PATCH v1 3/3] KVM: SVM: Add 5-level page table support for SVM Wei Huang
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=YQxdbq+yoTIJmpL+@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=wei.huang2@amd.com \
--cc=x86@kernel.org \
/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.