[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/3] XSM PIRQ and rcu_lock_target cleanup
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. -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |