Hi Quentin, On Fri, 14 Feb 2025 at 11:13, Quentin Perret <qperret@xxxxxxxxxx> wrote: > > 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. The more I think about it, I agree with you. I think that reasonable behavior (for kvm/arm64) would be to allow using guest_memfd with all VM types. If the VM type is a non-protected type, then its memory is considered shared by default and is mappable --- as long as the kconfig option is enabled. If VM is protected then the memory is not shared by default. What do you think Patrick? Do you need an explicit VM type? Cheers, /fuad > Cheers, > Quentin
