From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC][PATCH 02/13] introduce XENMEM_reserved_device_memory_map Date: Thu, 16 Apr 2015 16:24:09 +0100 Message-ID: <20150416152409.GM13443@deinos.phlegethon.org> References: <1428657724-3498-1-git-send-email-tiejun.chen@intel.com> <1428657724-3498-3-git-send-email-tiejun.chen@intel.com> <20150416145916.GF13441@deinos.phlegethon.org> <552FED140200007800072D70@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <552FED140200007800072D70@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 Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, yang.z.zhang@intel.com, Tiejun Chen List-Id: xen-devel@lists.xenproject.org At 16:10 +0100 on 16 Apr (1429200644), Jan Beulich wrote: > >>> On 16.04.15 at 16:59, wrote: > > At 17:21 +0800 on 10 Apr (1428686513), Tiejun Chen wrote: > >> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > >> index 2b5206b..36e5f54 100644 > >> --- a/xen/include/public/memory.h > >> +++ b/xen/include/public/memory.h > >> @@ -574,7 +574,37 @@ struct xen_vnuma_topology_info { > >> typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t; > >> DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t); > >> > >> -/* Next available subop number is 27 */ > >> +/* > >> + * For legacy reasons, some devices must be configured with special memory > >> + * regions to function correctly. The guest would take these regions > >> + * according to different user policies. > >> + */ > > > > I don't understand what this means. Can you try to write a comment > > that would tell an OS developer: > > - what the reserved device memory map actually means; and > > - what this hypercall does. > > For one, this is meant to be a tools only interface, hence the OS > developer shouldn't care much. And then I don't think we should > be explaining the RMRR concept here. Fair enough. How about: /* * On some legacy devices, certain guest-physical addresses cannot * safely be used to map guest RAM. This hypercall enumerates those * regions so the toolstack can avoid using them. */ Tim. > >> @@ -121,6 +121,8 @@ void iommu_dt_domain_destroy(struct domain *d); > >> > >> struct page_info; > >> > >> +typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt); > > > > This needs a comment describing what the return values are. > > Will do. > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel