Re: [RFC PATCH 04/19] memory: Introduce memory_region_can_be_private()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux