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: Tue, 4 Jun 2013 17:31:43 -0700 Message-ID: <20130604173143.7ef56db1@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51A8897602000078000D9F13@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 Fri, 31 May 2013 10:28:54 +0100 "Jan Beulich" wrote: > >>> On 25.05.13 at 03:25, Mukesh Rathor > >>> wrote: > > > + if ( xsm_add_to_physmap(XSM_TARGET, current->domain, d) ) > > + { > > + rcu_unlock_domain(d); > > + return -EPERM; > > + } > I realize there's another such bogus use of the function in the same > file, but you shouldn't propagate that mistake: The function has a > proper return value, and that's what should be used here instead > of forcing it to be -EPERM. Ok, changed. > > 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? thanks, M-