Re: [PATCH v5 08/12] hostmem: Support fully shared guest memfd to back a VM

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/11/26 14:06, Peter Xu wrote:
> On Thu, Sep 10, 2026 at 06:00:11PM -0500, Michael Roth wrote:
>> On Thu, Sep 10, 2026 at 10:54:09AM +0200, David Hildenbrand wrote:
>>>
>>> [...]
>>>
>>>
>>> There is a lot of uncertainty how guest_memfd would consume huge pages. So best
>>> to drop the "yet" that implies how it would be consumed (and that it would be
>>> called "hugetlb").
>>
>> Makes sense, will change this as suggested for v6
> 
> I'm just curious, any more info on this part?  Any link to existing work
> would help.

Ackerley has been mostly busy doing the in-place conversion, the hugetlb-related
patches he sent are a bit dated.

He's been recently looking into how to abstract memory providers for
guest_memfd, I think there were some upstream discussions related to that in
related context:

https://lore.kernel.org/r/CAEvNRgHbfx470HUBJhEUVKPKqsV0LnhX+wkD1TE-61fZy3jjUw@mail.gmail.com


> 
> At least from our side, we look for hugetlb-alike support on gmem.  I want
> to make sure what I understand still is valid, and it is still open to
> solve the postcopy problem.

Right, something like that will come. And I am not saying that we won't model it
as "guest memfd hugetlb" support in QEMU, but I wouldn't start documenting that
it will be modeled like that.

hugetlb will initially be used as a memory provider for hugetlb to allocate
larger pages, and guest_memfd will essentially strip these pages from hugetlb
details, turning them into simple large guest_memfd pages.

One idea is to support other pools, where also hugetlb could take pages from
these pools.

So it's just a matter of "we don't know how we will model it, and we don't know
whether it will be called hugetlb".

-- 
Cheers,

David