On Fri, Feb 14, 2025, Patrick Roy wrote: > On Fri, 2025-02-14 at 13:11 +0000, Fuad Tabba wrote: > > On Fri, 14 Feb 2025 at 12:37, Patrick Roy <roypat@xxxxxxxxxxxx> wrote: > >> On Fri, 2025-02-14 at 11:33 +0000, Fuad Tabba wrote: > >>> 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? Once guest_memfd can be mmap()'d, no. KVM_X86_SW_PROTECTED_VM was added for testing and development of guest_memfd largely because KVM can't support a "real" VM if KVM can't read/write guest memory through its normal mechanisms. The gap is most apparent on x86, but it holds true for arm64 as well. > >>>> 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. This aligns with what I see happening for x86, except that for non-protected VMs there will be no shared vs. private, because such VMs won't have a concept of private memory.
