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
