On Mon, Jul 31, 2023, Peter Xu wrote:
> On Mon, Jul 31, 2023 at 05:36:37PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 31, 2023 at 02:34:22PM -0700, Sean Christopherson wrote:
> > > On Mon, Jul 31, 2023, Peter Xu wrote:
> > > > On Mon, Jul 31, 2023 at 12:21:46PM -0400, Xiaoyao Li wrote:
> > > > > +bool memory_region_can_be_private(MemoryRegion *mr)
> > > > > +{
> > > > > + return mr->ram_block && mr->ram_block->gmem_fd >= 0;
> > > > > +}
> > > >
> > > > This is not really MAP_PRIVATE, am I right? If so, is there still chance
> > > > we rename it (it seems to be also in the kernel proposal all across..)?
> > >
> > > Yes and yes.
> > >
> > > > I worry it can be very confusing in the future against MAP_PRIVATE /
> > > > MAP_SHARED otherwise.
> > >
> > > Heh, it's already quite confusing at times. I'm definitely open to naming that
> > > doesn't collide with MAP_{PRIVATE,SHARED}, especially if someone can come with a
> > > naming scheme that includes a succinct way to describe memory that is shared
> > > between two or more VMs, but is accessible to _only_ those VMs.
> >
> > Standard solution is a technology specific prefix.
> > protect_shared, encrypt_shared etc.
>
> Agreed, a prefix could definitely help (if nothing better comes at last..).
> If e.g. "encrypted" too long to be applied everywhere in var names and
> functions, maybe it can also be "enc_{private|shared}".
FWIW, I would stay away from "encrypted", there is no requirement that the memory
actually be encrypted.
