Re: [ANNOUNCE] KVM Microconference at LPC 2023

[Sean Christopherson <seanjc@google.com>]

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