Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Aug 11, 2016 02:18, "Julien Grall" <julien.grall@xxxxxxx> wrote:
>
> Hello Tamas,
>
>
> On 10/08/2016 16:49, Tamas K Lengyel wrote:
>>
>> On Aug 10, 2016 03:52, "Julien Grall" <julien.grall@xxxxxxx
>> <mailto:julien.grall@xxxxxxx>> wrote:
>>>
>>> On 09/08/2016 21:16, Tamas K Lengyel wrote:
>>>>
>>>> On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall <julien.grall@xxxxxxx
>>
>> <mailto:julien.grall@xxxxxxx>> wrote:
>>>>
>>>> There is a rcu_lock_domain_by_any_id before we get to this check here,
>>>> so any other CPU looking to disable altp2m would be waiting there for
>>>> the current op to finish up, so there is no race condition AFAICT.
>>>
>>>
>>>
>>> No, rcu_lock_domain_by_any_id only prevents the domain to be fully
>>
>> destroyed by "locking" the rcu. It does not prevent multiple concurrent
>> access. You can look at the code if you are not convinced.
>>>
>>>
>>
>> Ah thanks for clarifying. Then indeed there could be concurrency issues
>> if there are multiple tools accessing this interface. Normally that
>> doesn't happen though but probably a good idea to enforce it anyway.
>
>
> Well, you need to think about the worst case scenario when you implement an interface. If you don't lock properly, the state in Xen may be corrupted. For instance Xen may think altp2m is active whilst it is not properly initialized.
>

Sure. We largely followed the x86 implementation here and there aren't any hvmops there that do synchronization like that, only the rcu lock is taken. Adding a domain_lock() should be fine though.

Tamas

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