From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [RFC][PATCH 2/5] xen:x86: introduce a new hypercall to get RMRR mappings Date: Fri, 15 Aug 2014 14:13:01 +0800 Message-ID: <53EDA4ED.2060505@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> <53EC0BE5.80102@intel.com> <53ECF70B02000078000BA7B8@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53ECF70B02000078000BA7B8@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Kevin Tian Cc: Yang Z Zhang , "xen-devel@lists.xen.org" , "ian.jackson@eu.citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On 2014/8/15 0:51, Jan Beulich wrote: >>>> On 14.08.14 at 03:07, wrote: >> 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, wrote: >>>>>> On 2014/8/8 23:45, Jan Beulich wrote: >>>>>>>>>> On 07.08.14 at 13:02, 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. > > I'd be fine with Kevin's suggestion (as I can't see any other > reserved memory maps to appear), but I'd also be fine with I double check this again and looks we already have the following structure definition that may be easy to confuse with XENMEM_reserved_memory_map, typedef struct xen_memory_reservation xen_memory_reservation_t; DEFINE_XEN_GUEST_HANDLE(xen_memory_reservation_t); > XENMEM_reserved_device_memory_map or some such to So I'd like to adopt this. Thanks Tiejun > suit your concerns. > > Jan > >