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.