Re: [Xen-devel] [PATCH 02/20] PVH xen: add XENMEM_add_to_physmap_range

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 16 May 2013, Jan Beulich wrote:
> >>> On 16.05.13 at 13:03, Stefano Stabellini 
> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Thu, 16 May 2013, Jan Beulich wrote:
> >> >>> On 16.05.13 at 01:05, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> >> >+        xatp.space = xatpr->space;
> >> >+        xatp.idx = idx;
> >> >+        xatp.gpfn = gpfn;
> >> >+        rc = xenmem_add_to_physmap_once(d, &xatp, xatpr->foreign_domid);
> >> 
> >> xatp has a domid field - why don't you use that instead of adding a
> >> new function parameter? I'm unclear anyway why two domain IDs
> >> are useful here at all - Ian, Stefano, for one I still can't spot any use
> >> of xen_add_to_physmap_range in tools and qemu (and hence can't
> >> see a clear use case), and then I doubt there's real use for one
> >> domain mapping GFNs from a second domain into a third one. If it's
> >> really dead code that got added here, shouldn't we drop it now
> >> rather than releasing 4.3 with it baked into the interface?
> > 
> > We use XENMEM_add_to_physmap_range to map foreign mfns in dom0 during
> > domain creation.
> 
> Hmm - for one, where is that code?

arch/arm/xen/enlighten.c:map_foreign_page


> And then - this involves only
> two domains, but the interface explicitly permits for three, and
> that aspect was what my query was about.
 
We are using two domains: DOMID_SELF and the foreign_domid. I take that
your point is that given that we are always using domid = DOMID_SELF,
that field is not actually useful? I guess that is correct however I
wouldn't go as far as changing that interface again only for that.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel