From: "Gowans, James" <jgowans@amazon.com>
To: "jgg@ziepe.ca" <jgg@ziepe.ca>
Cc: "quic_eberman@quicinc.com" <quic_eberman@quicinc.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"rppt@kernel.org" <rppt@kernel.org>,
"brauner@kernel.org" <brauner@kernel.org>,
"anthony.yznaga@oracle.com" <anthony.yznaga@oracle.com>,
"steven.sistare@oracle.com" <steven.sistare@oracle.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Durrant, Paul" <pdurrant@amazon.co.uk>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"seanjc@google.com" <seanjc@google.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Saenz Julienne, Nicolas" <nsaenz@amazon.es>, "Graf (AWS),
Alexander" <graf@amazon.de>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"jack@suse.cz" <jack@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 05/10] guestmemfs: add file mmap callback
Date: Sat, 2 Nov 2024 08:24:15 +0000 [thread overview]
Message-ID: <9df04c57f9d5f351bb1b4eeef764bf9ccc6711b1.camel@amazon.com> (raw)
In-Reply-To: <20241101134202.GB35848@ziepe.ca>
On Fri, 2024-11-01 at 10:42 -0300, Jason Gunthorpe wrote:
>
> On Fri, Nov 01, 2024 at 01:01:00PM +0000, Gowans, James wrote:
>
> > Thanks Jason, that sounds perfect. I'll work on the next rev which will:
> > - expose a filesystem which owns reserved/persistent memory, just like
> > this patch.
>
> Is this step needed?
>
> If the guest memfd is already told to get 1G pages in some normal way,
> why do we need a dedicated pool just for the KHO filesystem?
>
> Back to my suggestion, can't KHO simply freeze the guest memfd and
> then extract the memory layout, and just use the normal allocator?
>
> Or do you have a hard requirement that only KHO allocated memory can
> be preserved across kexec?
KHO can persist any memory ranges which are not MOVABLE. Provided that
guest_memfd does non-movable allocations then serialising and persisting
should be possible.
There are other requirements here, specifically the ability to be
*guaranteed* GiB-level allocations, have the guest memory out of the
direct map for secret hiding, and remove the struct page overhead.
Struct page overhead could be handled via HVO. But considering that the
memory must be out of the direct map it seems unnecessary to have struct
pages, and unnecessary to have it managed by an existing allocator. The
only existing 1 GiB allocator I know of is hugetlbfs? Let me know if
there's something else that can be used.
That's the main motivation for a separate pool allocated on early boot.
This is quite similar to hugetlbfs, so a natural question is if we could
use and serialise hugetlbfs instead, but that probably opens another can
of worms of complexity.
There's more than just the guest_memfds and their allocations to
serialise; it's probably useful to be able to have a directory structure
in the filesystem, POSIX file ACLs, and perhaps some other filesystem
metadata. For this reason I still think that having a new filesystem
designed for this use-case which creates guest_memfd objects when files
are opened is the way to go.
Let me know what you think.
JG
next prev parent reply other threads:[~2024-11-02 8:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 9:32 [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem James Gowans
2024-08-05 9:32 ` [PATCH 01/10] guestmemfs: Introduce filesystem skeleton James Gowans
2024-08-05 10:20 ` Christian Brauner
2024-08-05 9:32 ` [PATCH 02/10] guestmemfs: add inode store, files and dirs James Gowans
2024-08-05 9:32 ` [PATCH 03/10] guestmemfs: add persistent data block allocator James Gowans
2024-08-05 9:32 ` [PATCH 04/10] guestmemfs: support file truncation James Gowans
2024-08-05 9:32 ` [PATCH 05/10] guestmemfs: add file mmap callback James Gowans
2024-10-29 23:05 ` Elliot Berman
2024-10-30 22:18 ` Frank van der Linden
2024-11-01 12:55 ` Gowans, James
2024-10-31 15:30 ` Gowans, James
2024-10-31 16:06 ` Jason Gunthorpe
2024-11-01 13:01 ` Gowans, James
2024-11-01 13:42 ` Jason Gunthorpe
2024-11-02 8:24 ` Gowans, James [this message]
2024-11-04 11:11 ` Mike Rapoport
2024-11-04 14:39 ` Jason Gunthorpe
2024-11-04 10:49 ` Mike Rapoport
2024-08-05 9:32 ` [PATCH 06/10] kexec/kho: Add addr flag to not initialise memory James Gowans
2024-08-05 9:32 ` [PATCH 07/10] guestmemfs: Persist filesystem metadata via KHO James Gowans
2024-08-05 9:32 ` [PATCH 08/10] guestmemfs: Block modifications when serialised James Gowans
2024-08-05 9:32 ` [PATCH 09/10] guestmemfs: Add documentation and usage instructions James Gowans
2024-08-05 9:32 ` [PATCH 10/10] MAINTAINERS: Add maintainers for guestmemfs James Gowans
2024-08-05 14:32 ` [PATCH 00/10] Introduce guestmemfs: persistent in-memory filesystem Theodore Ts'o
2024-08-05 14:41 ` Paolo Bonzini
2024-08-05 19:47 ` Gowans, James
2024-08-05 19:53 ` Gowans, James
2024-08-05 20:01 ` Jan Kara
2024-08-05 23:29 ` Jason Gunthorpe
2024-08-06 8:26 ` Gowans, James
2024-08-06 8:12 ` Gowans, James
2024-08-06 13:43 ` David Hildenbrand
2024-08-07 23:45 ` David Matlack
2024-10-17 4:53 ` Vishal Annapurve
2024-11-01 12:53 ` Gowans, James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9df04c57f9d5f351bb1b4eeef764bf9ccc6711b1.camel@amazon.com \
--to=jgowans@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=brauner@kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.de \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nsaenz@amazon.es \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.co.uk \
--cc=quic_eberman@quicinc.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=steven.sistare@oracle.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).