Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 26 May 2023 09:39:06 -0700
In-Reply-To: <88db2d9cb42e471692ff1feb0b9ca855906a9d95.camel@amazon.com>
Mime-Version: 1.0
References: <2f19f26e-20e5-8198-294e-27ea665b706f@redhat.com> <88db2d9cb42e471692ff1feb0b9ca855906a9d95.camel@amazon.com>
Message-ID: <ZHDflnVNGw1fN6VD@google.com>
Subject: Re: [ANNOUNCE] KVM Microconference at LPC 2023
From:   Sean Christopherson <seanjc@google.com>
To:     James Gowans <jgowans@amazon.com>
Cc:     "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "maz@kernel.org" <maz@kernel.org>, Alexander Graf <graf@amazon.de>,
        Nicolas Saenz Julienne <nsaenz@amazon.es>
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Fri, May 26, 2023, James Gowans wrote:
> On Tue, 2023-05-09 at 11:55 +0200, Paolo Bonzini wrote:
> > Hi all!
> > 
> > We are planning on submitting a CFP to host a KVM Microconference at
> > Linux Plumbers Conference 2023. To help justify the proposal, we would
> > like to gather a list of folks that would likely attend, and crowdsource
> > a list of topics to include in the proposal.
> 
> Hi Paolo,
> 
> This MC sounds great! There are two topics I'd be keen to discuss, both in
> the KVM + memory-management realm:
> 
> 1. Guest and kernel memory persistence across kexec for live update.
> Specifically focussing on the host IOMMU pgtable persistence for DMA-
> passthrough devices to support kexec while guest-driven DMA is still
> running. There is some discussion happening now about this [1] and
> hopefully the discussion and prototyping will continue in the run up to
> LPC.

I don't think a KVM MC conference would be the right venue for this discussion.
IIUC, KVM does not need to be involved in preserving guest memory or the IOMMU
page tables.

> 2. Supporting more fine-grain memory management and access control APIs
> for the virtualisation case specifically, for use-cases around live
> migration, memory oversubscription, and "side-car" virtual machines. These
> use cases would benefit from kernel support for things like dynamically
> updating IOMMU and MMU permissions independently at fine granularity, all
> without actually modifying the VMAs, to support fine-grain handling. And
> linking this topic to the one above: being able to do these things when
> not backed by struct pages. (There may be some overlap with "KVM guest
> private memory" [2] here...)

Yes, there's overlap with guest private memory.  Though I actually think we should
start viewing it as "guest first" memory (I'm mentally thinking of it as guest_memfd()),
since there are potential benefits and applications beyond CoCo VMs for guest memory
that doesn't *need* to be mapped into host userspace.  If the guest_memfd() idea comes
to fruition, then KVM would *need* a way to specify guest memory protections without
VMAs.  So yes, definitely overlap :-)

If y'all are interested, guest_memfd() is the topic of discussion for the inaugural
KVM upstream call (PUCK)[*].  I would also be more than happy to carve out a PUCK
instance to discuss non-VMA-based MMU protections, i.e. we don't have to wait until
LPC to start hashing out the KVM API(s) and implementation.

[*] https://lore.kernel.org/all/20230525234735.2585977-1-seanjc@google.com