[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6bb76ce318651fcae796be57b77e10857eb73879.camel@intel.com>
Date: Thu, 28 Aug 2025 01:26:50 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>, "Zhao, Yan Y"
<yan.y.zhao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "Annapurve, Vishal" <vannapurve@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"michael.roth@....com" <michael.roth@....com>, "Weiny, Ira"
<ira.weiny@...el.com>
Subject: Re: [RFC PATCH 02/12] KVM: x86/mmu: Add dedicated API to map
guest_memfd pfn into TDP MMU
On Wed, 2025-08-27 at 17:54 -0700, Rick Edgecombe wrote:
> >
> > Then, what about setting
> > .max_level = PG_LEVEL_4K,
> > directly?
> >
> > Otherwise, the "(KVM_BUG_ON(level != PG_LEVEL_4K, kvm)" would be triggered
> > in
> > tdx_sept_set_private_spte().
>
> Yes this fails to boot a TD. With max_level = PG_LEVEL_4K it passes the full
> tests. I don't think it's ideal to encode PAGE.ADD details here though.
>
> But I'm not immediately clear what is going wrong. The old struct
> kvm_page_fault
> looks pretty similar. Did you root cause it?
Oh, duh. Because we are passing in the PFN now so it can't know the size. So
it's not about PAGE.ADD actually.
Sill, how about calling the function kvm_tdp_mmu_map_private_pfn_4k(), or
passing in the level?
Powered by blists - more mailing lists