On Mon, Oct 17, 2022 at 08:05:10PM +0100, Fuad Tabba wrote: > Hi, > > > > > Using both private_fd and userspace_addr is only needed in TDX and other > > > > confidential computing scenarios, pKVM may only use private_fd if the fd > > > > can also be mmaped as a whole to userspace as Sean suggested. > > > > > > That does work in practice, for now at least, and is what I do in my > > > current port. However, the naming and how the API is defined as > > > implied by the name and the documentation. By calling the field > > > private_fd, it does imply that it should not be mapped, which is also > > > what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM > > > would be mis/ab-using this interface, and that future changes could > > > cause unforeseen issues for pKVM. > > > > That is fairly enough. We can change the naming and the documents. > > > > > > > > Maybe renaming this to something like "guest_fp", and specifying in > > > the documentation that it can be restricted, e.g., instead of "the > > > content of the private memory is invisible to userspace" something > > > along the lines of "the content of the guest memory may be restricted > > > to userspace". > > > > Some other candidates in my mind: > > - restricted_fd: to pair with the mm side restricted_memfd > > - protected_fd: as Sean suggested before > > - fd: how it's explained relies on the memslot.flag. > > All these sound good, since they all capture the potential use cases. > Restricted might be the most logical choice if that's going to also > become the name for the mem_fd. Thanks, I will use 'restricted' for them. e.g.: - memfd_restricted() syscall - restricted_fd - restricted_offset The memslot flags will still be KVM_MEM_PRIVATE, since I think pKVM will create its own one? Chao > > Thanks, > /fuad > > > Thanks, > > Chao > > > > > > What do you think? > > > > > > Cheers, > > > /fuad > > > > > > > > > > > Thanks, > > > > Chao > > > > > > > > > > Cheers, > > > > > /fuad
