On Wed, Oct 05, 2022 at 04:04:05PM +0300, Jarkko Sakkinen wrote: > On Thu, Sep 15, 2022 at 10:29:07PM +0800, Chao Peng wrote: > > In memory encryption usage, guest memory may be encrypted with special > > key and can be accessed only by the VM itself. We call such memory > > private memory. It's valueless and sometimes can cause problem to allow > > userspace to access guest private memory. This patch extends the KVM > > memslot definition so that guest private memory can be provided though > > an inaccessible_notifier enlightened file descriptor (fd), without being > > mmaped into userspace. > > > > This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two > > additional KVM memslot fields private_fd/private_offset to allow > > userspace to specify that guest private memory provided from the > > private_fd and guest_phys_addr mapped at the private_offset of the > > private_fd, spanning a range of memory_size. > > > > The extended memslot can still have the userspace_addr(hva). When use, a > > single memslot can maintain both private memory through private > > fd(private_fd/private_offset) and shared memory through > > hva(userspace_addr). Whether the private or shared part is visible to > > guest is maintained by other KVM code. > > > > Since there is no userspace mapping for private fd so we cannot > > get_user_pages() to get the pfn in KVM, instead we add a new > > inaccessible_notifier in the internal memslot structure and rely on it > > to get pfn by interacting with the memory file systems. > > > > Together with the change, a new config HAVE_KVM_PRIVATE_MEM is added and > > right now it is selected on X86_64 for Intel TDX usage. > > > > To make code maintenance easy, internally we use a binary compatible > > alias struct kvm_user_mem_region to handle both the normal and the > > '_ext' variants. > > > > Co-developed-by: Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx> > > Signed-off-by: Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx> > > Signed-off-by: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx> > > What if userspace_addr would contain address of an extension structure, > if the flag is set, instead of shared address? I.e. interpret that field > differently (could be turned into union too ofc). > > That idea could be at least re-used, if there's ever any new KVM_MEM_* > flags that would need an extension. > > E.g. have struct kvm_userspace_memory_private, which contains shared > address, fd and the offset. Or add a new ioctl number instead of messing with the existing parameter structure, e.g. KVM_SET_USER_MEMORY_REGION_PRIVATE. With this alternative and the current approach in the patch, it would be better just to redefine the struct fields that are common. It actually would reduce redundancy because then there is no need to create that somewhat confusing kernel version of the same struct, right? You don't save any redundancy with this "embedded struct" approach. BR, Jarkko
