[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.