On Mon, 2024-08-05 at 20:29 -0300, Jason Gunthorpe wrote: > > On Mon, Aug 05, 2024 at 10:01:51PM +0200, Jan Kara wrote: > > > > 4. Device assignment: being able to use guestmemfs memory for > > > VFIO/iommufd mappings, and allow those mappings to survive and continue > > > to be used across kexec. > > That's a fun one. Proposals for that will be very interesting! Yup! We have an LPC session for this; looking forward to discussing more there: https://lpc.events/event/18/contributions/1686/ I'll be working on a iommufd RFC soon; should get it out before then. > > > To me the basic functionality resembles a lot hugetlbfs. Now I know very > > little details about hugetlbfs so I've added relevant folks to CC. Have you > > considered to extend hugetlbfs with the functionality you need (such as > > preservation across kexec) instead of implementing completely new filesystem? > > In mm circles we've broadly been talking about splitting the "memory > provider" part out of hugetlbfs into its own layer. This would include > the carving out of kernel memory at boot and organizing it by page > size to allow huge ptes. > > It would make alot of sense to have only one carve out mechanism, and > several consumers - hugetlbfs, the new private guestmemfd, this thing, > for example. The actual allocation in guestmemfs isn't too complex, basically just a hook in mem_init() (that's a bit yucky as it's arch-specific) and then a call to memblock allocator. That being said, the functionality for this patch series is currently intentionally limited: missing NUMA support, and only doing PMD (2 MiB) block allocations for files - we want PUD (1 GiB) where possible falling back to splitting to 2 MiB for smaller files. That will complicate things, so perhaps a memory provider will be useful when this gets more functionally complete. Keen to hear more! JG
