From: "Gowans, James" <jgowans@amazon.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"david@redhat.com" <david@redhat.com>,
"quic_eberman@quicinc.com" <quic_eberman@quicinc.com>
Cc: "Graf (AWS), Alexander" <graf@amazon.de>,
"Woodhouse, David" <dwmw@amazon.co.uk>
Subject: Re: [Invitation] bi-weekly guest_memfd upstream call on 2024-12-12
Date: Wed, 11 Dec 2024 13:53:59 +0000 [thread overview]
Message-ID: <7b5c8e67c48e082ed5c96bba2d536c9301fef8ef.camel@amazon.com> (raw)
In-Reply-To: <b9567cbf-8ad7-440a-8768-f4e7dbd2b5f7@redhat.com>
On Tue, 2024-12-10 at 15:25 +0100, David Hildenbrand wrote:
> In this meeting we'll likely discuss:
> * Patrick: KVM gmem MMIO access challenges and KVM_X86_SW_PROTECTED_VM
> for arm
> * Aneesh: Feasibility of 4 KiB guests on 64 KiB host
> * Persisting guest_memfd across reboot / guest_memfs (if James is around)
I should be around and will be keen to discuss this. Where we landed
last on this topic was that guestmemfs should be modified to use the
guest_memfd library code to instantiate a real guest_memfd file when a
guestmemfs file is opened. Essentially the guestmemfs persistence will
mostly be a custom allocator behind the in-development guest_memfd
library code, including the ability to restore guest_memfd mappings when
re-opening the file after kexec.
The main dependency here is on the guest_memfd library effort.
Discussion on how that's going and making sure that the guestmemfs
persistence use case is covered will be useful.
We need to make sure that the guest_memfd library supports:
1. Defining a custom allocator other than buddy-list managed pages so
that a persistent reserved memory pool can be used.
2. Being able to re-drive or fault in mappings for a file after kexec.
In all likelihood the allocator code path and equally restore previously
allocated pages.
3. Support huge/gigantic mappings
4. Support mmaping the guest_memfd file; for non-CoCo VMs this will be
necessary for PV devices. I realise that this is a whole can of worms
currently under discussion and not specific to this use case.
So, let's socialise this revised guestmemfs approach, and next steps for
the library development.
>
> And we'll continue our discussion on:
> * Challenges with supporting huge pages
> * Challenges with shared vs. private conversion
> * guest_memfd as a "library"
JG
Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07
next prev parent reply other threads:[~2024-12-11 13:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 12:30 [Invitation] bi-weekly guest_memfd upstream call on 2024-11-14 David Hildenbrand
2024-11-13 6:06 ` Chao Gao
2024-11-13 15:04 ` David Hildenbrand
2024-11-14 2:27 ` Chao Gao
2024-12-24 4:21 ` Alexey Kardashevskiy
2024-12-24 11:27 ` David Hildenbrand
2024-12-27 4:21 ` Alexey Kardashevskiy
2024-11-27 16:43 ` [Invitation] bi-weekly guest_memfd upstream call on 2024-12-05 David Hildenbrand
2024-12-10 14:25 ` [Invitation] bi-weekly guest_memfd upstream call on 2024-12-12 David Hildenbrand
2024-12-11 13:53 ` Gowans, James [this message]
2025-01-08 10:45 ` [Invitation] bi-weekly guest_memfd upstream call on 2025-01-09 David Hildenbrand
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=7b5c8e67c48e082ed5c96bba2d536c9301fef8ef.camel@amazon.com \
--to=jgowans@amazon.com \
--cc=david@redhat.com \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.de \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=quic_eberman@quicinc.com \
/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).