Re: [Qemu-devel] Help on TLB Flush

[Alexander Graf]

On 12.02.15 16:08, Mark Burton wrote:
> 
>> On 12 Feb 2015, at 16:01, Peter Maydell <address@hidden> wrote:
>>
>> On 12 February 2015 at 14:45, Alexander Graf <address@hidden> wrote:
>>>
>>>> On 12.02.2015, at 15:35, Mark Burton <address@hidden> wrote:
>>>> We are proposing to implement this by signalling all other CPU’s
>>>> to exit (and requesting they flush before re-starting). In other
>>>> words, this would happen asynchronously.
>>>
>>> For global flushes, give them a pointer payload along with the flush
>>> request and tell all cpus to increment it atomically. In your main
>>> thread, wait until *ptr == nKickedCpus.
>>
>> I bet this will not be the only situation where you want to
>> do an "get all other CPUs to do $something and wait til they
>> have done so" kind of operation, so some lightweight but generic
>> infrastructure for doing that would not be a bad plan. (Similarly
>> "get all other CPUs to stop, then I can do $something and let
>> the others continue”.)
> 
> We tried this - we ended up in knots.
> We had 2 CPU’s trying to flush at about the same time, both waiting for the 
> other.
> We had CPU’s trying to get the global mutex to finish what they were doing, 
> while being told to flush, 
> We had CPU’s in the global mutex trying to do something that would cause a 
> flush… etc....
> We had spaghetti with extra Bolognese sauce…
> 
> We eventually concluded, yes - in an infinite universe everything is 
> possible, but if we could simply do this ‘asynchronously’ then our lives 
> would be a LOT easier.
> e.g.  - ask all CPU’s to “exit and do something” is easy -  wait for them to 
> do that is a whole other problem…
> 
> Our question is - do we need this ‘sync’ (before the flush), or can we 
> actually allow CPU’s to flush themselves asynchronously….

The respective target architecture specs will tell you. And I very much
doubt that it is ok in most cases.


Alex