From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 02/18] PVH xen: add XENMEM_add_to_physmap_range Date: Wed, 5 Jun 2013 13:41:46 -0700 Message-ID: <20130605134146.2bb6b342@mantra.us.oracle.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> <20130604173143.7ef56db1@mantra.us.oracle.com> <51AF05C402000078000DB564@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51AF05C402000078000DB564@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: xen-devel List-Id: xen-devel@lists.xenproject.org On Wed, 05 Jun 2013 08:32:52 +0100 "Jan Beulich" wrote: > >>> On 05.06.13 at 02:31, Mukesh Rathor > >>> wrote: > >> I also vaguely recall having pointed out in a much earlier review > >> that this functionality is lacking a counterpart in > >> compat_arch_memory_op(). > > > > Hmm.. confused how/why a 64bit PVH go thru compat_arch_memory_op()? > > Can you pl explain? > > Iirc the new hypercall isn't restricted to PVH guests, and hence > needs a compat implementation regardless of 32-bit PVH not > existing yet. This patch does not introduce the hcall, it was introduced much earlier. It implements the portion needed for 64bit PVH. It also documents the intention in the public header file for the subcall it uses: #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom, * XENMEM_add_to_physmap_range only. * (PVH x86 only) */ thanks, Mukesh