Agreed
Cheers
Mark.
> On 13 Feb 2015, at 14:30, Lluís Vilanova wrote:
>
> Mark Burton writes:
>
>>> On 13 Feb 2015, at 08:24, Peter Maydell wrote:
>>>
>>> On 13 February 2015 at 07:16, Mark Burton wrote:
If the kernel is doing this - then effectively - for X86, each CPU only
flush’
Mark Burton writes:
>> On 13 Feb 2015, at 08:24, Peter Maydell wrote:
>>
>> On 13 February 2015 at 07:16, Mark Burton wrote:
>>> If the kernel is doing this - then effectively - for X86, each CPU only
>>> flush’s it’s own TLB (from the perspective of Qemu) - correct?
>>> (in which case, for Qem
On 13/02/2015 10:37, Mark Burton wrote:
> the memory barrier is on the cpu requesting the flush isn’t it (not
> on the CPU that is being flushed)?
Oops, I misread Peter's explanation.
In that case, perhaps DMB can be treated in a similar way as WFI, using
cpu->halted. Queueing work on other CP
the memory barrier is on the cpu requesting the flush isn’t it (not on the CPU
that is being flushed)?
Cheers
Mark.
> On 13 Feb 2015, at 10:34, Paolo Bonzini wrote:
>
>
>
> On 12/02/2015 22:57, Peter Maydell wrote:
>> The only
>> requirement is that if the CPU that did the TLB maintenance
>>
On 12/02/2015 22:57, Peter Maydell wrote:
> The only
> requirement is that if the CPU that did the TLB maintenance
> op executes a DMB (barrier) then the TLB op must finish
> before the barrier completes execution. So you could split
> the "kick off TLB invalidate" and "make sure all CPUs
> are d
> On 13 Feb 2015, at 08:24, Peter Maydell wrote:
>
> On 13 February 2015 at 07:16, Mark Burton wrote:
>> If the kernel is doing this - then effectively - for X86, each CPU only
>> flush’s it’s own TLB (from the perspective of Qemu) - correct?
>> (in which case, for Qemu itself - for x86) - we d
On 13 February 2015 at 07:16, Mark Burton wrote:
> If the kernel is doing this - then effectively - for X86, each CPU only
> flush’s it’s own TLB (from the perspective of Qemu) - correct?
> (in which case, for Qemu itself - for x86) - we dont need to implement
> a global flush, and hence we dont n
Up top - thanks Peter, I think you may give us an idea !
> On 12 Feb 2015, at 23:10, Lluís Vilanova wrote:
>
> Mark Burton writes:
>
>>> On 12 Feb 2015, at 16:38, Alexander Graf wrote:
>>>
>>>
>>>
>>> On 12.02.15 15:58, Peter Maydell wrote:
On 12 February 2015 at 14:45, Alexander Graf
Mark Burton writes:
>> On 12 Feb 2015, at 16:38, Alexander Graf wrote:
>>
>>
>>
>> On 12.02.15 15:58, Peter Maydell wrote:
>>> On 12 February 2015 at 14:45, Alexander Graf wrote:
almost nobody except x86 does global flushes
>>>
>>> All ARM TLB maintenance operations have both "this CPU
On 12 February 2015 at 15:38, Alexander Graf wrote:
> On 12.02.15 15:58, Peter Maydell wrote:
>> All ARM TLB maintenance operations have both "this CPU only"
>> and "all TLBs in the Inner Shareable domain" [that's ARM-speak
>> for "every CPU core in the cluster"] variants (the latter
>> being the
On 12 February 2015 at 15:19, Alexander Graf wrote:
> On 12.02.15 16:08, Mark Burton wrote:
>> 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
> On 12 Feb 2015, at 16:31, Dr. David Alan Gilbert wrote:
>
> * Mark Burton (mark.bur...@greensocs.com) wrote:
>>
>>> On 12 Feb 2015, at 16:01, Peter Maydell wrote:
>>>
>>> On 12 February 2015 at 14:45, Alexander Graf wrote:
> On 12.02.2015, at 15:35, Mark Burton wrote:
> We a
> On 12 Feb 2015, at 16:38, Alexander Graf wrote:
>
>
>
> On 12.02.15 15:58, Peter Maydell wrote:
>> On 12 February 2015 at 14:45, Alexander Graf wrote:
>>> almost nobody except x86 does global flushes
>>
>> All ARM TLB maintenance operations have both "this CPU only"
>> and "all TLBs in the
On 12.02.15 15:58, Peter Maydell wrote:
> On 12 February 2015 at 14:45, Alexander Graf wrote:
>> almost nobody except x86 does global flushes
>
> All ARM TLB maintenance operations have both "this CPU only"
> and "all TLBs in the Inner Shareable domain" [that's ARM-speak
> for "every CPU core i
* Mark Burton (mark.bur...@greensocs.com) wrote:
>
> > On 12 Feb 2015, at 16:01, Peter Maydell wrote:
> >
> > On 12 February 2015 at 14:45, Alexander Graf wrote:
> >>
> >>> On 12.02.2015, at 15:35, Mark Burton wrote:
> >>> We are proposing to implement this by signalling all other CPU???s
> >
On 12.02.15 16:08, Mark Burton wrote:
>
>> On 12 Feb 2015, at 16:01, Peter Maydell wrote:
>>
>> On 12 February 2015 at 14:45, Alexander Graf wrote:
>>>
On 12.02.2015, at 15:35, Mark Burton wrote:
We are proposing to implement this by signalling all other CPU’s
to exit (and requ
OK - Alex - your implication is that it has to be atomic, we need the sync…
:-(
I have a horrid feeling that the atomicity of global flush can’t be causing the
(almost, but not quite reproducible) errors we’re seeing - but… anyway ;-)
Cheers
Mark.
> On 12 Feb 2015, at 15:45, Alexander
> On 12 Feb 2015, at 16:01, Peter Maydell wrote:
>
> On 12 February 2015 at 14:45, Alexander Graf wrote:
>>
>>> On 12.02.2015, at 15:35, Mark Burton wrote:
>>> We are proposing to implement this by signalling all other CPU’s
>>> to exit (and requesting they flush before re-starting). In other
On 12 February 2015 at 14:45, Alexander Graf wrote:
>
>> On 12.02.2015, at 15:35, Mark Burton 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 f
On 12 February 2015 at 14:45, Alexander Graf wrote:
> almost nobody except x86 does global flushes
All ARM TLB maintenance operations have both "this CPU only"
and "all TLBs in the Inner Shareable domain" [that's ARM-speak
for "every CPU core in the cluster"] variants (the latter
being the TLB *I
> On 12.02.2015, at 15:35, Mark Burton wrote:
>
>
> TLB Flush:
>
> We have spent a few days on this issue, and still haven’t resolved the best
> path.
>
> Our solution seems to work, most of the time, but we still have some strange
> issues - so I want to check that what we are proposing ha
21 matches
Mail list logo
