Re: [Xen-devel] [PATCH 0/3] XSM PIRQ and rcu_lock_target cleanup

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-01-23 at 14:51 +0000, Daniel De Graaf wrote:
> On 01/23/2013 09:43 AM, Ian Campbell wrote:
> > On Wed, 2013-01-23 at 14:37 +0000, Daniel De Graaf wrote:
> >> On 01/18/2013 04:23 AM, Ian Campbell wrote:
> >>> On Thu, 2013-01-17 at 18:55 +0000, Daniel De Graaf wrote:
> >>>> These three patches finish up the XSM IS_PRIV reworking, in addition to
> >>>> the patches posted by Ian and Lars fixing things for ARM. I did not
> >>>> include a patch removing the rcu_lock_target_domain_by_id function
> >>>> because it's still referenced in ARM at the moment, but it looks like
> >>>> those locations are being changed (or will be changed in the future).
> >>>
> >>> Am I right that the appropriate transformation is:
> >>>   rc = rcu_lock_target_domain_by_id(domid, &d);
> >>> becomes:
> >>>   d = rcu_lock_domain_by_any_id(a.domid);
> >>>         if ( d == NULL )
> >>>             return -ESRCH;
> >>>
> >>>   rc = xsm_SOMETHING(XSM_TARGET, d, PARAMS);
> >>>   if ( rc )
> >>>       ... unlock .. return or goto err
> >>>
> >>> Ian.
> >>>
> >>
> >> Yes, this is correct. Looking at today's xen-unstable, only the
> >> XENMAPSPACE_gmfn_foreign mapping needs a new ARM-only XSM hook.
> > 
> > Does it? Even on x86 xsm only has a single xsm_add_to_physmap covering
> > all XENMAPSPACE cases and ARM matches this.
> > 
> > Ian.
> > 
> 
> Since x86 doesn't implement XENMAPSPACE_gmfn_foreign, it doesn't need
> another check. The additional check would ensure that the domain doing
> the mapping has access to the foreign pages, while the existing checks
> verify that it has the right to change the physmap being modified.

Ah, right yes.

x86 will need this too when PVH lands.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel