On Thursday 28 Mar 2024 at 11:32:21 (+0100), David Hildenbrand wrote: > ... does that mean that for pKVM with protected VMs, "shared" pages are also > never migratable/swappable? In our current implementation, yes, KVM keeps its longterm GUP pin on pages that are shared back. And we might want to retain this behaviour in the short term, even with guest_memfd or using the hybrid approach you suggested. But that could totally be relaxed in the future, it's "just" a matter of adding extra support to the hypervisor for that. That has not been prioritized yet since the number of shared pages in practice is relatively small for current use-cases, so ballooning was a better option (and in the case of ballooning, we do drop the GUP pin). But that's clearly on the TODO list! > The whole reason I brought up the guest_memfd+memfd pair idea is that you > would similarly be able to do the conversion in the kernel, BUT, you'd never > be able to mmap+GUP encrypted pages. > > Essentially you're using guest_memfd for what it was designed for: private > memory that is inaccessible. Ack, that sounds pretty reasonable to me. But I think we'd still want to make sure the other users of guest_memfd have the _desire_ to support huge pages, migration, swap (probably longer term), and related features, otherwise I don't think a guest_memfd-based option will really work for us :-) Thanks, Quentin
