On Tuesday 11 Feb 2025 at 17:09:20 (+0000), Quentin Perret wrote: > Hi Patrick, > > On Tuesday 11 Feb 2025 at 16:32:31 (+0000), Patrick Roy wrote: > > I was hoping that SW_PROTECTED_VM will be the VM type that something > > like Firecracker could use, e.g. an interface to guest_memfd specifically > > _without_ pKVM, as Fuad was saying. > > I had, probably incorrectly, assumed that we'd eventually want to allow > gmem for all VMs, including traditional KVM VMs that don't have anything > special. Perhaps the gmem support could be exposed via a KVM_CAP in this > case? > > Anyway, no objection to the proposed approach in this patch assuming we > will eventually have HW_PROTECTED_VM for pKVM VMs, and that _that_ can be > bit 31 :). Thinking about this a bit deeper, I am still wondering what this new SW_PROTECTED VM type is buying us? Given that SW_PROTECTED VMs accept both guest-memfd backed memslots and traditional HVA-backed memslots, we could just make normal KVM guests accept guest-memfd memslots and get the same thing? Is there any reason not to do that instead? Even though SW_PROTECTED VMs are documented as 'unstable', the reality is this is UAPI and you can bet it will end up being relied upon, so I would prefer to have a solid reason for introducing this new VM type. Cheers, Quentin
