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@xxxxxxxxxx
