[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 02/20] PVH xen: add XENMEM_add_to_physmap_range
On Wed, 15 May 2013 10:58:43 +0100 "Jan Beulich" <JBeulich@xxxxxxxx> wrote: > >>> On 15.05.13 at 02:52, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> > >>> wrote: > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -4519,7 +4519,8 @@ static int handle_iomem_range(unsigned long > > s, unsigned long e, void *p) > > static int xenmem_add_to_physmap_once( > > struct domain *d, > > - const struct xen_add_to_physmap *xatp) > > + const struct xen_add_to_physmap *xatp, > > + domid_t foreign_domid) > > { > > struct page_info *page = NULL; > > unsigned long gfn = 0; /* gcc ... */ > > @@ -4646,7 +4647,7 @@ static int xenmem_add_to_physmap(struct > > domain *d, > > I know I said this before: This patch can't be complete, or else the > new function parameter would actually get used. With the way > things are, if this patch gets applied, a user of the new XENMEM_ > sub-op would not get the expected behavior. > No, the new foreign_domid parameter is meaningful for only the XENMAPSPACE_gmfn_foreign OP which is defined in patch 0018. So we should be OK here. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |