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

[Julien Grall <julien.grall@xxxxxxx>]

On 11/08/2016 16:41, Tamas K Lengyel wrote:
> On Aug 11, 2016 02:18, "Julien Grall" <julien.grall@xxxxxxx
> <mailto: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>
> > > <mailto: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>
> > > <mailto: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.
I would be curious to know why the x86 implementation does not need this 
lock.
Cheers,

--
Julien Grall

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