From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. Date: Mon, 8 Oct 2012 17:59:25 -0700 Message-ID: <20121008175925.105e78de@mantra.us.oracle.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> <1349444550.20946.102.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1349444550.20946.102.camel@zakaz.uk.xensource.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: Ian Campbell Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Fri, 5 Oct 2012 14:42:30 +0100 Ian Campbell wrote: > On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote: > [... snip dozens of pointless lines -- please trim your quotes...] > > > > - return -ENOSYS; > > > + int err; > > > + struct remap_data data; > > > + > > > + /* TBD: Batching, current sole caller only does page at > > > a time */ > > > + if (nr > 1) > > > + return -EINVAL; > > > > It looks like that this implementation of > > xen_remap_domain_mfn_range is capable of handling nr > 1, so why > > this return -EINVAL? > > Hrm, yes. I think I just blindly copied that from the pvh > implementation. > > [...] PVH was using a different mechanism earlier, pfn from high up memory address space. So it was doing one at a time. It can be removed now.