Re: [Xen-devel] [RFC][PATCH 2/5] xen:x86: introduce a new hypercall to get RMRR mappings

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/8/14 2:21, Tian, Kevin wrote:
> > From: Chen, Tiejun
> > Sent: Tuesday, August 12, 2014 5:40 PM
> >
> > On 2014/8/12 20:19, Jan Beulich wrote:
> > > > > > On 12.08.14 at 12:55, <tiejun.chen@xxxxxxxxx> wrote:
> > > > On 2014/8/8 23:45, Jan Beulich wrote:
> > > > > > > > On 07.08.14 at 13:02, <tiejun.chen@xxxxxxxxx> wrote:
> > > > > > +/*
> > > > > > + * Returns the RMRR memory map as it was when the domain
> > > > > > + * was started.
> > > > > > + */
> > > > > > +#define XENMEM_RMRR_memory_map           26
> > > > > > +typedef struct e820map rmrr_e820_t;
> > > > > > +DEFINE_XEN_GUEST_HANDLE(rmrr_e820_t);
> > > > > Again just as a general remark: What in the world does the "e820"
> > > > > in here mean?
> > > > I will redefine a struct to represent this to avoid any confusion.
> > > And just to avoid another needless round: The term RMRR shouldn't
> > > be in the hypercall public interface definitions either. This needs to
> > > be properly abstracted.
> > Without such a term RMRR I can't figure out what definition should be
> > better as you expect, I guess you already have a better case so please
> > share it to avoid further discussion.
> XENMEM_reserved_memory_map
Okay, but I prefer to XENMEM_DEVICE_reserved_memory_map or 
XENMEM_PLATFORM_reserved_memory_map since RMRR seems to be dedicated to 
device or platform, right?
Anyway, I'm fine as well once Jan have no any objection to this.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel