[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6cc36b662dffaf0aa2a2f389f073daa2d63a530b.camel@intel.com>
Date: Fri, 08 Jul 2022 14:15:20 +1200
From: Kai Huang <kai.huang@...el.com>
To: isaku.yamahata@...el.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH v7 033/102] KVM: x86/mmu: Add address conversion
functions for TDX shared bits
On Mon, 2022-06-27 at 14:53 -0700, isaku.yamahata@...el.com wrote:
> From: Rick Edgecombe <rick.p.edgecombe@...el.com>
I don't think this is appropriate any more. You can add Co-developed-by I
guess.
>
> TDX repurposes one GPA bits (51 bit or 47 bit based on configuration) to
> indicate the GPA is private(if cleared) or shared (if set) with VMM. If
> GPA.shared is set, GPA is converted existing conventional EPT pointed by
> EPTP. If GPA.shared bit is cleared, GPA is converted by Secure-EPT(S-EPT)
Not sure whether Secure EPT has even been mentioned before in this series. If
not, perhaps better to explain it here. Or not sure whether you need to mention
S-EPT at all.
> TDX module manages. VMM has to issue SEAM call to TDX module to operate on
SEAM call -> SEAMCALL
> S-EPT. e.g. populating/zapping guest page or shadow page by TDH.PAGE.{ADD,
> REMOVE} for guest page, TDH.PAGE.SEPT.{ADD, REMOVE} S-EPT etc.
Not sure why you want to mention those particular SEAMCALLs.
>
> Several hooks needs to be added to KVM MMU to support TDX. Add a function
needs -> need.
Not sure why you need first sentence at all.
But I do think you should mention adding per-VM scope 'gfn_shared_mask' thing.
> to check if KVM MMU is running for TDX and several functions for address
> conversation between private-GPA and shared-GPA.
>
> Signed-off-by: Isaku Yamahata <isaku.yamahata@...el.com>
> ---
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/mmu.h | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e5d4e5b60fdc..2c47aab72a1b 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1339,7 +1339,9 @@ struct kvm_arch {
> */
> u32 max_vcpu_ids;
>
> +#ifdef CONFIG_KVM_MMU_PRIVATE
> gfn_t gfn_shared_mask;
> +#endif
As Xiaoyao said, please introduce gfn_shared_mask in this patch.
And by applying this patch, nothing will prevent you to turn on INTEL_TDX_HOST
and KVM_INTEL, which also turns on KVM_MMU_PRIVATE.
So 'kvm_arch::gfn_shared_mask' is guaranteed to be 0? If not, can legal
(shared) GFN for normal VM be potentially treated as private?
If yes, perhaps explicitly call out in changelog so people don't need to worry
about?
> };
>
> struct kvm_vm_stat {
> diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> index f8192864b496..ccf0ba7a6387 100644
> --- a/arch/x86/kvm/mmu.h
> +++ b/arch/x86/kvm/mmu.h
> @@ -286,4 +286,36 @@ static inline gpa_t kvm_translate_gpa(struct kvm_vcpu *vcpu,
> return gpa;
> return translate_nested_gpa(vcpu, gpa, access, exception);
> }
> +
> +static inline gfn_t kvm_gfn_shared_mask(const struct kvm *kvm)
> +{
> +#ifdef CONFIG_KVM_MMU_PRIVATE
> + return kvm->arch.gfn_shared_mask;
> +#else
> + return 0;
> +#endif
> +}
> +
> +static inline gfn_t kvm_gfn_shared(const struct kvm *kvm, gfn_t gfn)
> +{
> + return gfn | kvm_gfn_shared_mask(kvm);
> +}
> +
> +static inline gfn_t kvm_gfn_private(const struct kvm *kvm, gfn_t gfn)
> +{
> + return gfn & ~kvm_gfn_shared_mask(kvm);
> +}
> +
> +static inline gpa_t kvm_gpa_private(const struct kvm *kvm, gpa_t gpa)
> +{
> + return gpa & ~gfn_to_gpa(kvm_gfn_shared_mask(kvm));
> +}
> +
> +static inline bool kvm_is_private_gpa(const struct kvm *kvm, gpa_t gpa)
> +{
> + gfn_t mask = kvm_gfn_shared_mask(kvm);
> +
> + return mask && !(gpa_to_gfn(gpa) & mask);
> +}
> +
> #endif
Powered by blists - more mailing lists