From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V3 PATCH 5/9] PVH dom0: implement XENMEM_add_to_physmap_range for x86 Date: Tue, 3 Dec 2013 11:49:16 -0800 Message-ID: <20131203114916.60668a60@mantra.us.oracle.com> References: <1385519230-21132-1-git-send-email-mukesh.rathor@oracle.com> <1385519230-21132-6-git-send-email-mukesh.rathor@oracle.com> <529C8F6D0200007800108B8E@nat28.tlf.novell.com> <20131202160512.66d321d0@mantra.us.oracle.com> <529D9ACB02000078001092AB@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VnvzF-0004JY-VZ for xen-devel@lists.xenproject.org; Tue, 03 Dec 2013 19:50:26 +0000 In-Reply-To: <529D9ACB02000078001092AB@nat28.tlf.novell.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: Jan Beulich Cc: george.dunlap@eu.citrix.com, xen-devel , keir.xen@gmail.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On Tue, 03 Dec 2013 07:48:11 +0000 "Jan Beulich" wrote: > >>> On 03.12.13 at 01:05, Mukesh Rathor > >>> wrote: > > On Mon, 02 Dec 2013 12:47:25 +0000 > > "Jan Beulich" wrote: > >> And as noted a number of times before - I don't think that's > >> appropriate. There's nothing keeping non-PVH guests from using > >> this interface, and hence it should either be uniformly available > >> to all of them, or uniformly unavailable. I'm not intending to > >> apply such a half baked thing. > > > > I am sorry for your frustration, but as I said before, doing it is > > not straightforward as it involves creating a new version of > > XLAT_add_to_physmap which unfortunately is generated via > > python/shell scripts. > > Exactly - all of the basics are being taken care of for you. You > don#t even need to worry about how these XLAT_* macros > are being generated. You only need to use them (taking other > similar code as reference if needed). No, the existing macro can't be used because of extra field foreign_domid that needs to be copied also, not to mention the gpfns array that need to be handled too. We need to create/generate a new macro because the foreign_domid doesn't exist in struct xen_add_to_physmap, and the gpfns and errs arrays need to be considered. thanks mukesh