Hi, > > > > Actually, for pKVM, there is no need for the guest memory to be > > GUP'able at all if we use the new inaccessible_get_pfn(). > > If pKVM can use inaccessible_get_pfn() to get pfn and can avoid GUP (I > think that is the major concern?), do you see any other gap from > existing API? Actually for this part no, there aren't any gaps and inaccessible_get_pfn() is sufficient. > > This of > > course goes back to what I'd mentioned before in v7; it seems that > > representing the memslot memory as a file descriptor should be > > orthogonal to whether the memory is shared or private, rather than a > > private_fd for private memory and the userspace_addr for shared > > memory. The host can then map or unmap the shared/private memory using > > the fd, which allows it more freedom in even choosing to unmap shared > > memory when not needed, for example. > > 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. 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". What do you think? Cheers, /fuad > > Thanks, > Chao > > > > Cheers, > > /fuad
