linux-kernel - Re: [PATCH 05/10] guestmemfs: add file mmap callback

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: <a6a39b440b969318b446ddf862f9a6a235b8c6da.camel@amazon.com>
Date: Fri, 1 Nov 2024 12:55:04 +0000
From: "Gowans, James" <jgowans@...zon.com>
To: "quic_eberman@...cinc.com" <quic_eberman@...cinc.com>, "fvdl@...gle.com"
	<fvdl@...gle.com>
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>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"Woodhouse, David" <dwmw@...zon.co.uk>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Saenz
 Julienne, Nicolas" <nsaenz@...zon.es>, "Durrant, Paul"
	<pdurrant@...zon.co.uk>, "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"jack@...e.cz" <jack@...e.cz>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "jgg@...pe.ca" <jgg@...pe.ca>
Subject: Re: [PATCH 05/10] guestmemfs: add file mmap callback

On Wed, 2024-10-30 at 15:18 -0700, Frank van der Linden wrote:
> On Tue, Oct 29, 2024 at 4:06 PM Elliot Berman <quic_eberman@...cinc.com> wrote:
> > 
> > On Mon, Aug 05, 2024 at 11:32:40AM +0200, James Gowans wrote:
> > > Make the file data usable to userspace by adding mmap. That's all that
> > > QEMU needs for guest RAM, so that's all be bother implementing for now.
> > > 
> > > When mmaping the file the VMA is marked as PFNMAP to indicate that there
> > > are no struct pages for the memory in this VMA. Remap_pfn_range() is
> > > used to actually populate the page tables. All PTEs are pre-faulted into
> > > the pgtables at mmap time so that the pgtables are usable when this
> > > virtual address range is given to VFIO's MAP_DMA.
> > 
> > Thanks for sending this out! I'm going through the series with the
> > intention to see how it might fit within the existing guest_memfd work
> > for pKVM/CoCo/Gunyah.
> > 
> > It might've been mentioned in the MM alignment session -- you might be
> > interested to join the guest_memfd bi-weekly call to see how we are
> > overlapping [1].
> > 
> > [1]: https://lore.kernel.org/kvm/ae794891-fe69-411a-b82e-6963b594a62a@redhat.com/T/
> > 
> > ---
> > 
> > Was the decision to pre-fault everything because it was convenient to do
> > or otherwise intentionally different from hugetlb?
> > 
> 
> It's memory that is placed outside of of page allocator control, or
> even outside of System RAM - VM_PFNMAP only. So you don't have much of
> a choice..
> 
> In general, for things like guest memory or persistent memory, even if
> struct pages were available, it doesn't seem all that useful to adhere
> to the !MAP_POPULATE standard, why go through any faults to begin
> with?
> 
> For guest_memfd: as I understand it, it's folio-based. And this is
> VM_PFNMAP memory without struct pages / folios. So the main task there
> is probably to teach guest_memfd about VM_PFNMAP memory. That would be
> great, since it then ties in guest_memfd with external guest memory.

Exactly - I think all of the comments on this series are heading in a
similar direction: let's add a custom reserved (PFNMAP) persistent
memory allocator behind guest_memfd and expose that as a filesystem.
This will be what the next version of patch series will do.

JG