[PATCH v4 04/28] KVM: x86/mmu: Add dedicated API to map guest_memfd pfn into TDP MMU
Binbin Wu
binbin.wu at linux.intel.com
Fri Oct 31 00:58:22 PDT 2025
On 10/31/2025 4:09 AM, Sean Christopherson wrote:
> Add and use a new API for mapping a private pfn from guest_memfd into the
> TDP MMU from TDX's post-populate hook instead of partially open-coding the
> functionality into the TDX code. Sharing code with the pre-fault path
> sounded good on paper, but it's fatally flawed as simulating a fault loses
> the pfn, and calling back into gmem to re-retrieve the pfn creates locking
> problems, e.g. kvm_gmem_populate() already holds the gmem invalidation
> lock.
>
> Providing a dedicated API will also removing several MMU exports that
> ideally would not be exposed outside of the MMU, let alone to vendor code.
> On that topic, opportunistically drop the kvm_mmu_load() export. Leave
> kvm_tdp_mmu_gpa_is_mapped() alone for now; the entire commit that added
> kvm_tdp_mmu_gpa_is_mapped() will be removed in the near future.
>
> Gate the API on CONFIG_KVM_GUEST_MEMFD=y as private memory _must_ be backed
> by guest_memfd. Add a lockdep-only assert to that the incoming pfn is
> indeed backed by guest_memfd, and that the gmem instance's invalidate lock
> is held (which, combined with slots_lock being held, obviates the need to
> check for a stale "fault").
>
> Cc: Michael Roth <michael.roth at amd.com>
> Cc: Yan Zhao <yan.y.zhao at intel.com>
> Cc: Ira Weiny <ira.weiny at intel.com>
> Cc: Vishal Annapurve <vannapurve at google.com>
> Cc: Rick Edgecombe <rick.p.edgecombe at intel.com>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe at intel.com>
> Reviewed-by: Kai Huang <kai.huang at intel.com>
> Link: https://lore.kernel.org/all/20250709232103.zwmufocd3l7sqk7y@amd.com
> Signed-off-by: Sean Christopherson <seanjc at google.com>
Reviewed-by: Binbin Wu <binbin.wu at linux.intel.com>
More information about the linux-riscv
mailing list