[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPTztWYZtO6Bfphdrfr6Pbc-v4WAgCG+iCJJK26aS1f1AdNbVw@mail.gmail.com>
Date: Wed, 30 Oct 2024 15:18:25 -0700
From: Frank van der Linden <fvdl@...gle.com>
To: Elliot Berman <quic_eberman@...cinc.com>
Cc: James Gowans <jgowans@...zon.com>, linux-kernel@...r.kernel.org,
Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>, Steve Sistare <steven.sistare@...cle.com>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
Anthony Yznaga <anthony.yznaga@...cle.com>, Mike Rapoport <rppt@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
Jason Gunthorpe <jgg@...pe.ca>, linux-fsdevel@...r.kernel.org,
Usama Arif <usama.arif@...edance.com>, kvm@...r.kernel.org,
Alexander Graf <graf@...zon.com>, David Woodhouse <dwmw@...zon.co.uk>,
Paul Durrant <pdurrant@...zon.co.uk>, Nicolas Saenz Julienne <nsaenz@...zon.es>
Subject: Re: [PATCH 05/10] guestmemfs: add file mmap callback
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.
- Frank
Powered by blists - more mailing lists