Re: Pmemfs/guestmemfs discussion recap and open questions

[Vishal Annapurve <vannapurve@google.com>]

On Sat, Oct 26, 2024 at 11:37 AM David Rientjes <rientjes@google.com> wrote:
>
> On Wed, 16 Oct 2024, David Rientjes wrote:
>
> > ----->o-----
> > My takeaway: based on the feedback that was provided in the discussion:
> >
> >  - we need an allocator abstraction for persistent memory that can return
> >    memory with various characteristics: 1GB or not, kernel direct map or
> >    not, HVO or not, etc.
> >
> >  - built on top of that, we need the ability to carve out very large
> >    ranges of memory (cloud provider use case) with NUMA awareness on the
> >    kernel command line
> >
>
> Following up on this, I think this physical memory allocator would also be
> possible to use as a backend for hugetlb.  Hopefully this would be an
> allocator that would be generally useful for multiple purposes, something
> like a mm/phys_alloc.c.
>
> Frank van der Linden may also have thoughts on the above?
>
> >  - we also need the ability to be able to dynamically resize this or
> >    provide hints at allocation time that memory must be persisted across
> >    kexec to support the non-cloud provider use case
> >
> >  - we need a filesystem abstraction that map memory of the type that is
> >    requested, including guest_memfd and then deal with all the fun of
> >    multitenancy since it would be drawing from a finite per-NUMA node
> >    pool of persistent memory
> >
> >  - absolutely critical to this discussion is defining what is the core
> >    infrastructure that is required for a generally acceptable solution
> >    and then what builds off of that to be more special cased (like the
> >    cloud provider use case or persistent tmpfs use case)
> >
> > We're looking to continue that discussion here and then come together
> > again in a few weeks.
> >
>
> We'll be looking to schedule some more time to talk about this topic in
> the Wednesday, November 13 instance of the Linux MM Alignment Session.
>
> After that, I think it would be quite useful to break out the set of
> people that are interested in persisting guest memory across kexec and KHO
> into a separate series to accelerate discussion and next stpes.  Getting
> the requirements and design locked down are critical, so happy to
> facilitate that to any extent possible and welcome everybody interested in
> discussing it.

I think there is a nice overlap between requirements for the guest
memory persistence and guest_memfd 1G page support for
confidential/non-confidential VMs. Memory persistence of guest_memfd
backed CoCo VMs and KHO will be a critical usecase for us at Google as
well, so I am interested in further discussion here.

Regards,
Vishal

>
> James, for the guestmemfs discussions, would this work for you?
>
> Alexander, same question for you regarding the KHO work?
>
> It's a global community, so the timing won't work for eveyrbody.  We'd
> plan on sending out summaries of these discussions, such as in this email,
> to solicit feedback and ideas from everybody.
>
> If you're not on the To: or Cc: list already, please email me separatel if
> you're interested in participating and then we can find a regular time.
>
> This is exciting!