On 9/21/2023 5:11 PM, David Hildenbrand wrote:
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.
Thanks for that information. Personally, I don't believe "to back most
VMs with gmem", but that's a different discussion.
As a development vehicle to get TDX up and running it might be very
valuable indeed. But it doesn't necessarily have to be merged in QEMU
for that case -- especially in a semi-finished form.
It's true and I agree with it. I'll drop the KVM_X86_SW_PROTECTED_VM
part in next version.
How would you like this series to proceed in next version? only the
patches of gmem support without a user? or together with next QEMU TDX
series?
