----- Original Message -----
> Il 16/09/2014 14:12, Andrew Jones ha scritto:
> >> > Should it at least write 1 to the spinlock?
> > I thought about that. So on one hand we might get a somewhat functional
> > synchronization mechanism, which may be enough for some unit test that
> > doesn't enable caches, but still needs it. On the other hand, we know
> > its broken, so we don't really want any unit tests that need
> > synchronization
> > and don't enable caches. I chose to not write a 1 in the hope that if
> > a unit test introduces a race, that that race will be easier to expose
> > and fix. That said, I'm not strongly biased, as we'd still have a race,
> > which may or may not be easy to expose, either way. So if the majority
> > prefers a best effort approach, then I'll spin a v2.
>
> The case I was thinking about was something like
>
> spin_lock()
> enable caches
> start other processors
> spin_unlock()
>
> I'm not sure if it makes sense though. :)
I don't think we need to worry about this case. AFAIU, enabling the
caches for a particular cpu shouldn't require any synchronization.
So we should be able to do
enable caches
spin_lock
start other processors
spin_unlock
drew
>
> Paolo
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
