Re: [RFC PATCH v4 00/14] KVM: Restricted mapping of guest_memfd at the host and arm64 support

[David Hildenbrand <david@redhat.com>]

On 20.01.25 10:26, Vlastimil Babka wrote:
> On 1/16/25 10:19, Fuad Tabba wrote:
>> Hi Ackerley,
>>
>> On Thu, 16 Jan 2025 at 00:35, Ackerley Tng <ackerleytng@google.com> wrote:
>>>
>>> Registration of the folio_put() callback only happens if the VMM
>>> actually tries to do vcpu_run(). For 4K folios I think this is okay
>>> since the 4K folio can be freed via the transition state K -> state I,
>>> but for hugetlb folios that have been split for sharing with userspace,
>>> not getting a folio_put() callback means never putting the hugetlb folio
>>> together. Hence, relying on vcpu_run() to add the folio_put() callback
>>> leaves a way that hugetlb pages can be removed from the system.
>>>
>>> I think we should try and find a path forward that works for both 4K and
>>> hugetlb folios.
>>
>> I agree, this could be an issue, but we could find other ways to
>> trigger the callback for huge folios. The important thing I was trying
>> to get to is how to have the callback and be able to register it.
>>
>>> IIUC page._mapcount and page.page_type works as a union because
>>> page_type is only set for page types that are never mapped to userspace,
>>> like PGTY_slab, PGTY_offline, etc.
>>
>> In the last guest_memfd sync, David Hildenbrand mentioned that that
>> would be a temporary restriction since the two structures would
>> eventually be decoupled, work being done by Matthew Wilcox I believe.
> 
> Note the "temporary" might be few years still, it's a long-term project.

Right, nobody knows how long it will actually take. Willy thinks the 
part that would be required here might be feasible in the nearer future: 
"'d like to lay out some goals for the coming year. I think we can 
accomplish a big goal this year" [1]

[1] https://lore.kernel.org/all/Z37pxbkHPbLYnDKn@casper.infradead.org/T/#u

-- 
Cheers,

David / dhildenb