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).
