From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [RFC][PATCH 2/5] xen:x86: introduce a new hypercall
 to get RMRR mappings
Date: Thu, 14 Aug 2014 09:07:49 +0800
Message-ID: <53EC0BE5.80102@intel.com>
References: <1407409371-31728-1-git-send-email-tiejun.chen@intel.com>
	<1407409371-31728-3-git-send-email-tiejun.chen@intel.com>
	<53E50CB4020000780002AB34@mail.emea.novell.com>
	<53E9F2AD.1090505@intel.com>
	<53EA2277020000780002B978@mail.emea.novell.com>
	<53EAB3F0.3050808@intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D1260367C2@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D1260367C2@SHSMSX101.ccr.corp.intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Tian, Kevin" <kevin.tian@intel.com>, Jan Beulich <JBeulich@suse.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>, "ian.campbell@citrix.com" <ian.campbell@citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

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@intel.com> wrote:
>>>> On 2014/8/8 23:45, Jan Beulich wrote:
>>>>>>>> On 07.08.14 at 13:02, <tiejun.chen@intel.com> 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