On Fri, 2024-10-18 at 08:50 +0100, David Hildenbrand wrote: > On 18.10.24 09:15, Patrick Roy wrote: >> >> >> 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". > > It's likely not what Peter meant, though. > > I think there are three scenarios: > > (a) Secure CoCo VMs: private is protected by HW > (b) Semi-secured non-CoCo VMs: private is removed from the directmap > (c) Non-CoCo VMs: only shared memory > > Does that match what you have in mind? Are there other cases? Yeah, I'm after your case (b). I suppose I will not call it just "non-CoCo" anymore then :) > -- > Cheers, > > David / dhildenb >
