[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e2d9f4a1e886721e59452a0cd5d553f0d32d7f1.camel@intel.com>
Date: Thu, 28 Aug 2025 02:13:36 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "pbonzini@...hat.com" <pbonzini@...hat.com>, "seanjc@...gle.com"
<seanjc@...gle.com>
CC: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "kvm@...r.kernel.org"
<kvm@...r.kernel.org>, "Annapurve, Vishal" <vannapurve@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Zhao, Yan Y"
<yan.y.zhao@...el.com>, "michael.roth@....com" <michael.roth@....com>,
"Weiny, Ira" <ira.weiny@...el.com>
Subject: Re: [RFC PATCH 01/12] KVM: TDX: Drop PROVE_MMU=y sanity check on
to-be-populated mappings
On Tue, 2025-08-26 at 17:05 -0700, Sean Christopherson wrote:
> Drop TDX's sanity check that an S-EPT mapping isn't zapped between creating
> said mapping and doing TDH.MEM.PAGE.ADD, as the check is simultaneously
> superfluous and incomplete. Per commit 2608f1057601 ("KVM: x86/tdp_mmu:
> Add a helper function to walk down the TDP MMU"), the justification for
> introducing kvm_tdp_mmu_gpa_is_mapped() was to check that the target gfn
> was pre-populated, with a link that points to this snippet:
>
> : > One small question:
> : >
> : > What if the memory region passed to KVM_TDX_INIT_MEM_REGION hasn't been pre-
> : > populated? If we want to make KVM_TDX_INIT_MEM_REGION work with these regions,
> : > then we still need to do the real map. Or we can make KVM_TDX_INIT_MEM_REGION
> : > return error when it finds the region hasn't been pre-populated?
> :
> : Return an error. I don't love the idea of bleeding so many TDX details into
> : userspace, but I'm pretty sure that ship sailed a long, long time ago.
>
> But that justification makes little sense for the final code, as simply
> doing TDH.MEM.PAGE.ADD without a paranoid sanity check will return an error
> if the S-EPT mapping is invalid (as evidenced by the code being guarded
> with CONFIG_KVM_PROVE_MMU=y).
>
> The sanity check is also incomplete in the sense that mmu_lock is dropped
> between the check and TDH.MEM.PAGE.ADD, i.e. will only detect KVM bugs that
> zap SPTEs in a very specific window.
>
> Removing the sanity check will allow removing kvm_tdp_mmu_gpa_is_mapped(),
> which has no business being exposed to vendor code.
>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
I guess I asked that small question :-)
Reviewed-by: Kai Huang <kai.huang@...el.com>
Powered by blists - more mailing lists