From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V7 PATCH 5/7] pvh: change xsm_add_to_physmap Date: Wed, 19 Feb 2014 18:37:13 -0800 Message-ID: <20140219183713.1aa2418f@mantra.us.oracle.com> References: <1387247911-28846-1-git-send-email-mukesh.rathor@oracle.com> <1387247911-28846-6-git-send-email-mukesh.rathor@oracle.com> <20140127175550.4cc67171@mantra.us.oracle.com> <52E7951802000078001177F6@nat28.tlf.novell.com> <20140128180802.152b3f8d@mantra.us.oracle.com> <1390992026.31814.63.camel@kazak.uk.xensource.com> <20140129113846.GA54797@deinos.phlegethon.org> <1390995662.31814.76.camel@kazak.uk.xensource.com> <20140129114837.GB54797@deinos.phlegethon.org> <1390996295.31814.84.camel@kazak.uk.xensource.com> <20140129173315.592e593e@mantra.us.oracle.com> <52F7B213.3000302@linaro.org> <1392039724.5117.94.camel@kazak.uk.xensource.com> <52F8ED31.609@linaro.org> <1392046038.26657.19.camel@kazak.uk.xensource.com> <52F8F13E.1070308@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WGJVv-0004Qx-PB for xen-devel@lists.xenproject.org; Thu, 20 Feb 2014 02:37:27 +0000 In-Reply-To: <52F8F13E.1070308@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: xen-devel , Tim Deegan , Ian Campbell , Jan Beulich , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On Mon, 10 Feb 2014 15:33:18 +0000 Julien Grall wrote: > On 02/10/2014 03:27 PM, Ian Campbell wrote: > > On Mon, 2014-02-10 at 15:16 +0000, Julien Grall wrote: > >> Hi Ian, > >> > >> On 02/10/2014 01:42 PM, Ian Campbell wrote: > >>> On Sun, 2014-02-09 at 16:51 +0000, Julien Grall wrote: > >>>> Hello Mukesh, > >>>> > >>>> On 30/01/14 01:33, Mukesh Rathor wrote: > >>>>>>> I'm not sure what you mean: > >>>>>>> - the code that Mukesh is adding doesn't have a struct > >> > >> For ARM, a call to xc_map_foreign_page will end up to > >> XENMEM_add_to_physmap_range(XENMAPSPACE_gmfn_foreign). > >> > >> For both architecture, you can look at the function > >> xen_remap_map_domain_mfn_range (implemented differently on ARM and > >> x86) which is the last function called before going to the > >> hypervisor. > >> > >> If we don't modify the hypercall XENMEM_add_to_physmap, we will > >> have a add a new way to map Xen page for xentrace & co. > > > > Wouldn't it be incorrect to generically return OK for mapping a > > DOMID_XEN owned page -- at least something needs to validate that > > the particular mfn being mapped is supposed to be shared with the > > guest in question. > > It's already the case. By default a xen heap page doesn't belong to > DOMID_XEN. Xen has to explicitly call share_xen_page_with_privileged > guess (see an example in xen/common/trace.c:244) to set DOMID_XEN to > the given page. So, how about following: +++ b/xen/common/domain.c @@ -484,8 +484,20 @@ struct domain *rcu_lock_domain_by_any_id(domid_t dom) int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d) { - if ( (*d = rcu_lock_domain_by_id(dom)) == NULL ) + + if ( (dom == DOMID_XEN && (*d = rcu_lock_domain(dom_xen)) == NULL) || + (dom != DOMID_XEN && (*d = rcu_lock_domain_by_id(dom)) == NULL) ) + return -ESRCH; + Ack/Nack? Thanks Mukesh