Re: [Xen-devel] lock in vhpet

[Keir Fraser <keir@xxxxxxx>]

On 17/04/2012 04:26, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:

> Hi keir
> 
> I noticed that the changeset 15289 introuduced locking to platform timers. And
> you mentioned that it only handy for correctness. Are there some potential
> issues which is fixed by this patch? If not, I wonder why we need those locks?

Yes, issues were fixed by the patch. That's why I bothered to implement it.
However I think the observed issues were with protecting the mechanisms in
vpt.c, and the other locking at least partially may be overly cautious.

> I think it should be OS's responsibly to guarantee the access sequentially,
> not hypervisor. Am I right?

It depends. Where an access is an apparently-atomic memory-mapped access,
but implemented as a sequence of operations in the hypervisor, the
hypervisor might need to maintain atomicity through locking.

> I don't know whether all those locks are necessary, but at least the lock for
> vhpet, especially the reading lock, is not required.

This is definitely not true, for example locking is required around calls to
create_periodic_time(), to serialise them. So in general the locking I
added, even in vhpet.c is required. If you have a specific hot path you are
looking to optimise, and especially if you have numbers to back that up,
then we can consider specific localised optimisations to avoid locking where
we can reason it is not needed.

 -- Keir

> best regards
> yang
> 



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