Hi David, On Fri, Jun 21, 2024 at 9:44 AM David Hildenbrand <[email protected]> wrote: > > >> Again from that thread, one of most important aspects guest_memfd is that > >> VMAs > >> are not required. Stating the obvious, lack of VMAs makes it really hard > >> to drive > >> swap, reclaim, migration, etc. from code that fundamentally operates on > >> VMAs. > >> > >> : More broadly, no VMAs are required. The lack of stage-1 page tables > >> are nice to > >> : have; the lack of VMAs means that guest_memfd isn't playing second > >> fiddle, e.g. > >> : it's not subject to VMA protections, isn't restricted to host mapping > >> size, etc. > >> > >> [1] https://lore.kernel.org/all/[email protected] > >> [2] https://lore.kernel.org/all/[email protected] > > > > I wonder if it might be more productive to also discuss this in one of > > the PUCKs, ahead of LPC, in addition to trying to go over this in LPC. > > I don't know in which context you usually discuss that, but I could > propose that as a topic in the bi-weekly MM meeting. > > This would, of course, be focused on the bigger MM picture: how to mmap, > how how to support huge pages, interaction with page pinning, ... So > obviously more MM focused once we are in agreement that we want to > support shared memory in guest_memfd and how to make that work with core-mm. > > Discussing if we want shared memory in guest_memfd might be betetr > suited for a different, more CC/KVM specific meeting (likely the "PUCKs" > mentioned here?).
Sorry, I should have given more context on what a PUCK* is :) It's a periodic (almost weekly) upstream call for KVM. [*] https://lore.kernel.org/all/[email protected]/ But yes, having a discussion in one of the mm meetings ahead of LPC would also be great. When do these meetings usually take place, to try to coordinate across timezones. Cheers, /fuad > -- > Cheers, > > David / dhildenb >
