Re: [Qemu-devel] Help on TLB Flush

[Alexander Graf <agraf@suse.de>]

On 12.02.15 16:08, Mark Burton wrote:
> 
>> On 12 Feb 2015, at 16:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On 12 February 2015 at 14:45, Alexander Graf <agraf@suse.de> wrote:
>>>
>>>> On 12.02.2015, at 15:35, Mark Burton <mark.burton@greensocs.com> 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