linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

  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).