From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 02/18] PVH xen: add
 XENMEM_add_to_physmap_range
Date: Fri, 31 May 2013 10:38:40 +0100
Message-ID: <1369993120.5199.46.camel@zakaz.uk.xensource.com>
References: <1369445137-19755-1-git-send-email-mukesh.rathor@oracle.com>
	<1369445137-19755-3-git-send-email-mukesh.rathor@oracle.com>
	<51A8897602000078000D9F13@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <51A8897602000078000D9F13@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Fri, 2013-05-31 at 10:28 +0100, Jan Beulich wrote:
> >>> On 25.05.13 at 03:25, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> >  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)
> 
> The patch could be a bit smaller afaict if you used the otherwise
> unused here domain ID field in xatp for passing the domain ID you
> care about here (I hinted at that in the last round already, where
> I also asked Stefano why we have three domains here in the first
> place).

This interface is already used on ARM, I don't think we want PVH to use
a different variation of the same thing so I don't think it is right to
put this on Mukesh.

AFAICT the existing xenmem ops all take an explicit target domain here,
rather than assuming that the target is the caller, this includes the
non-ranged add_to_physmap variant.

So I think the existing XENMEM_add_to_physmap_range interface is
consistent with the rest of that API, which I think is worthwhile even
if it only ever gets used with DOMID_SELF in practice (we have several
such interfaces, I think).

In any case I'm not sure we can rule out a future need to be able to do
this sort of operation on another domain -- at least not to the extent
of worrying about changing it now that it exists.

Ian.