|
[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 |