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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Regards,

--
Julien Grall

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