when to allocate KVM gmem with KVM_GUEST_MEMFD_ALLOW_HUGEPAGE. The
easiest solution is create KVM gmem with KVM_GUEST_MEMFD_ALLOW_HUGEPAGE
only when memory backend is HostMemoryBackendFile of hugetlbfs.
Good question.
Probably "if the memory backend uses huge pages, also use huge pages for the
private gmem" makes sense.
... but it becomes a mess with preallocation ... which is what people should
actually be using with hugetlb. Andeventual double memory-consumption ...
but maybe that's all been taken care of already?
Probably it's best to leave hugetlb support as future work and start with
something minimal.
3. What is KVM_X86_SW_PROTECTED_VM going to look like? and do we need it?
Why implement it when you have to ask others for a motivation? ;)
Personally, I'm not sure if it is really useful, especially in this state.
Yeah, as of today, KVM_X86_SW_PROTECTED_VM is mainly a development vehicle,
e.g. so that testing gmem doesn't require TDX/SNP hardware, debugging gmem
guests
isn't brutally painful, etc.
Longer term, I have aspirations of being able to back most VMs with gmem, but
that's going to require quite a bit more work, e.g. gmem needs to be mappable
(when hardware allows it) so that gmem doesn't all but require double mapping,
KVM obviously needs to be able to read/write gmem, etc.
The value proposition is that having a guest-first memory type will allow KVM to
optimize and harden gmem in ways that wouldn't be feasible for a more generic
memory implementation. E.g. memory isn't mapped into host userspace by default
(makes it harder to accidentally corrupt the guest), the guest can have *larger*
mappings than host userspace, guest memory can be served from a dedicated pool
(similar-ish to hugetlb), the pool can be omitted from the direct map, etc.