linux-kernel - Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ecbbd25ccddcdf79b90fdfd25ac62ade6cfd01c.camel@amazon.com>
Date: Tue, 6 Aug 2024 08:26:21 +0000
From: "Gowans, James" <jgowans@...zon.com>
To: "jack@...e.cz" <jack@...e.cz>, "jgg@...pe.ca" <jgg@...pe.ca>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "rppt@...nel.org"
	<rppt@...nel.org>, "brauner@...nel.org" <brauner@...nel.org>, "Graf (AWS),
 Alexander" <graf@...zon.de>, "anthony.yznaga@...cle.com"
	<anthony.yznaga@...cle.com>, "steven.sistare@...cle.com"
	<steven.sistare@...cle.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Durrant, Paul" <pdurrant@...zon.co.uk>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Woodhouse,
 David" <dwmw@...zon.co.uk>, "Saenz Julienne, Nicolas" <nsaenz@...zon.es>,
	"muchun.song@...ux.dev" <muchun.song@...ux.dev>, "viro@...iv.linux.org.uk"
	<viro@...iv.linux.org.uk>, "nh-open-source@...zon.com"
	<nh-open-source@...zon.com>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem

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