On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object / gmemfd object (when created) can have a flag marking that it's always shared and can never be converted to private for any page within.
What is non-CoCo? Does it include the private/shared concept?
I used that to represent the possible gmemfd use cases outside confidential computing.
So the private/shared things should still be around as fundamental property of gmemfd, but it should be always shared and no convertion needed for the whole lifecycle of the gmemfd when marked !CoCo.
But what does private mean in this context?
Is it just like a bit of additional hypervisor security that the page is not mapped anyplace except the KVM stage 2 and the hypervisor can cause it to become mapped/shared at any time? But the guest has no idea about this?
Jason
Yes, this is pretty much exactly what I'm after when I say "non-CoCo". No direct map entries to provide defense-in-depth for guests against various speculative execution issues, but not a full confidential computing setup (e.g. the guest should be completely oblivious to this, and not require any modifications).