Re: [PATCH v11 15/46] KVM: guest_memfd: Call arch make_shared callback for to-shared conversion

[Naveen N Rao <naveen@kernel.org>]

On Tue, Sep 29, 2026 at 08:01:45AM -0500, Michael Roth wrote:
> On Tue, Sep 29, 2026 at 03:10:41PM +0530, Naveen N Rao wrote:
> > On Wed, Aug 26, 2026 at 12:44:40PM -0700, Sean Christopherson wrote:
> > > On Wed, Aug 26, 2026, Ackerley Tng wrote:
> > 
> > Can this be a problem with gmem hugepages? Not sure how that is going to 
> > look like, so this may be covered in other ways.
> > 
> > But, as it exists today, if the guest converts part of a 2M page to 
> > shared, then this skips zapping the SPTEs from the call in 
> > kvm_gmem_invalidate_start(). sev_gmem_make_shared() then issues PSMASH 
> > to convert RMP entry to 4k entries and we end up with 2M NPT+4K RMP. If 
> > the guest then writes to any private page in that range, 
> > page_fault_can_be_fast() returns true, fast_page_fault() only checks 
> > permissions with spte_permission_fault() and does not do anything.  
> > sev_handle_rmp_fault() also does not issue a zap since it finds that the 
> > RMP entry is already 4k, and we end up in a loop.
> 
> In Ackerley's hugetlb series, gmem will split the underlying folio to 4K in
> that case. I assume, if we end up adopting Sean's proposed optimization, we'd
> update the attr_filter to force a zap if there's a demotion, similarly to how
> kvm_gmem_punch_hole() handles it in this series.

Ah, nice - that would be better.

> 
> I think as a general rule of thumb though we'd decided that guessing
> too hard at what hugepages will need is best left to hugepage series
> itself (TDX prep work aside), because it always ends up different than
> expected :)

Got it, that makes sense. Will consider adding WARN_ON_ONCE() so the 
dependency is clear.


Thanks,
Naveen