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}".
Thanks,
--
Peter Xu
