On Mon, Jul 25, 2022, Chao Peng wrote: > On Thu, Jul 21, 2022 at 05:58:50PM +0000, Sean Christopherson wrote: > > On Thu, Jul 21, 2022, Chao Peng wrote: > > > On Thu, Jul 21, 2022 at 03:34:59PM +0800, Wei Wang wrote: > > > > > > > > > > > > On 7/21/22 00:21, Sean Christopherson wrote: > > > > Maybe you could tag it with cgs for all the confidential guest support > > > > related stuff: e.g. kvm_vm_ioctl_set_cgs_mem() > > > > > > > > bool is_private = ioctl == KVM_MEMORY_ENCRYPT_REG_REGION; > > > > ... > > > > kvm_vm_ioctl_set_cgs_mem(, is_private) > > > > > > If we plan to widely use such abbr. through KVM (e.g. it's well known), > > > I'm fine. > > > > I'd prefer to stay away from "confidential guest", and away from any VM-scoped > > name for that matter. User-unmappable memmory has use cases beyond hiding guest > > state from the host, e.g. userspace could use inaccessible/unmappable memory to > > harden itself against unintentional access to guest memory. > > > > > I actually use mem_attr in patch: https://lkml.org/lkml/2022/7/20/610 > > > But I also don't quite like it, it's so generic and sounds say nothing. > > > > > > But I do want a name can cover future usages other than just > > > private/shared (pKVM for example may have a third state). > > > > I don't think there can be a third top-level state. Memory is either private to > > the guest or it's not. There can be sub-states, e.g. memory could be selectively > > shared or encrypted with a different key, in which case we'd need metadata to > > track that state. > > > > Though that begs the question of whether or not private_fd is the correct > > terminology. E.g. if guest memory is backed by a memfd that can't be mapped by > > userspace (currently F_SEAL_INACCESSIBLE), but something else in the kernel plugs > > that memory into a device or another VM, then arguably that memory is shared, > > especially the multi-VM scenario. > > > > For TDX and SNP "private vs. shared" is likely the correct terminology given the > > current specs, but for generic KVM it's probably better to align with whatever > > terminology is used for memfd. "inaccessible_fd" and "user_inaccessible_fd" are > > a bit odd since the fd itself is accesible. > > > > What about "user_unmappable"? E.g. > > > > F_SEAL_USER_UNMAPPABLE, MFD_USER_UNMAPPABLE, KVM_HAS_USER_UNMAPPABLE_MEMORY, > > MEMFILE_F_USER_INACCESSIBLE, user_unmappable_fd, etc... > > For KVM I also think user_unmappable looks better than 'private', e.g. > user_unmappable_fd/KVM_HAS_USER_UNMAPPABLE_MEMORY sounds more > appropriate names. For memfd however, I don't feel that strong to change > it from current 'inaccessible' to 'user_unmappable', one of the reason > is it's not just about unmappable, but actually also inaccessible > through direct ioctls like read()/write(). Heh, I _knew_ there had to be a catch. I agree that INACCESSIBLE is better for memfd.
