* Richard Henderson (r...@twiddle.net) wrote:
> On 03/03/2015 07:47 AM, Dr. David Alan Gilbert wrote:
> > That works for ARM where you have to terminate a ldrex with a strex or
> > clrex,
> > but not all architectures have the equivalent of a clrex; most as I remember
> > just let you do an ldrex
On 03/03/2015 07:47 AM, Dr. David Alan Gilbert wrote:
> That works for ARM where you have to terminate a ldrex with a strex or clrex,
> but not all architectures have the equivalent of a clrex; most as I remember
> just let you do an ldrex equivalent, decide you don't want to do the strex
> equiva
we’ll try and clean a patch up to show just this…….
THANKS!
Cheers
Mark.
> On 3 Mar 2015, at 16:34, Paolo Bonzini wrote:
>
>
>
> On 03/03/2015 16:33, Mark Burton wrote:
>>
>>> On 3 Mar 2015, at 16:32, Paolo Bonzini wrote:
>>>
>>>
>>>
>>> On 03/03/2015 16:29, Mark Burton wrote:
>>
On 03/03/2015 16:33, Mark Burton wrote:
>
>> On 3 Mar 2015, at 16:32, Paolo Bonzini wrote:
>>
>>
>>
>> On 03/03/2015 16:29, Mark Burton wrote:
>>>
>>> ps. on our bug - we believe somehow the STREX is being marked as
>>> failed, but actually succeeds to write something. There are only 3
>>> way
> On 3 Mar 2015, at 16:32, Paolo Bonzini wrote:
>
>
>
> On 03/03/2015 16:29, Mark Burton wrote:
>>
>> ps. on our bug - we believe somehow the STREX is being marked as
>> failed, but actually succeeds to write something. There are only 3
>> ways the strex can fail: 1/ the address doesn't matc
On 03/03/2015 16:29, Mark Burton wrote:
>
> ps. on our bug - we believe somehow the STREX is being marked as
> failed, but actually succeeds to write something. There are only 3
> ways the strex can fail: 1/ the address doesn't match - in which case
> no ST will be attempted 2/ the value doesn'
* Mark Burton (mark.bur...@greensocs.com) wrote:
>
> > On 3 Mar 2015, at 16:32, Paolo Bonzini wrote:
> >
> >
> >
> > On 03/03/2015 16:29, Mark Burton wrote:
> >>
> >> ps. on our bug - we believe somehow the STREX is being marked as
> >> failed, but actually succeeds to write something. There
Hi Peter, thanks for the feedback
So - what we have discovered - using the slow path as discussed has a
significant performance hit (no surprise), likewise the user-mode exit
mechanism. However we are investigating that in parallel...
However, for now, we have left the TCG doing the majority of
On 27 February 2015 at 16:54, Mark Burton wrote:
>
>> On 26 Feb 2015, at 23:56, Peter Maydell wrote:
>> cpu_physical_memory_rw would bypass the TLB and so be much slower.
>> Make sure you use the functions which go via the TLB if you do
>> this in a helper (and remember that they will longjmp out
> On 26 Feb 2015, at 23:56, Peter Maydell wrote:
>
> On 27 February 2015 at 03:09, Frederic Konrad
> wrote:
>> On 29/01/2015 16:17, Peter Maydell wrote:
>>>
>>> On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive acce
On 27 February 2015 at 03:09, Frederic Konrad wrote:
> On 29/01/2015 16:17, Peter Maydell wrote:
>>
>> On 16 January 2015 at 17:19, wrote:
>>>
>>> From: KONRAD Frederic
>>>
>>> This adds a lock to avoid multiple exclusive access at the same time in
>>> case of
>>> TCG multithread.
>> All the s
> Am 26.02.2015 um 19:09 schrieb Frederic Konrad :
>
>> On 29/01/2015 16:17, Peter Maydell wrote:
>>> On 16 January 2015 at 17:19, wrote:
>>> From: KONRAD Frederic
>>>
>>> This adds a lock to avoid multiple exclusive access at the same time in
>>> case of
>>> TCG multithread.
>>>
>>> Sign
On 2 February 2015 at 08:31, Frederic Konrad wrote:
>> * This is making no attempt to learn from or unify with
>> the existing attempts at handling exclusives in linux-user.
>> When we've done this work we should have a single
>> mechanism for handling exclusives in a multithreaded
>
On 29/01/2015 16:17, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time in case of
TCG multithread.
Signed-off-by: KONRAD Frederic
Hi Peter,
All the same comments I had on this patch earlier
On 16 January 2015 at 17:19, wrote:
> From: KONRAD Frederic
>
> This adds a lock to avoid multiple exclusive access at the same time in case
> of
> TCG multithread.
>
> Signed-off-by: KONRAD Frederic
All the same comments I had on this patch earlier still apply:
* I think adding mutex handl
fred.kon...@greensocs.com writes:
> From: KONRAD Frederic
>
> This adds a lock to avoid multiple exclusive access at the same time in case
> of
> TCG multithread.
>
> Signed-off-by: KONRAD Frederic
>
> V1 -> V2:
> Removed qemu_mutex_destroy().
> ---
> target-arm/cpu.c | 14 +++
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time in case of
TCG multithread.
Signed-off-by: KONRAD Frederic
V1 -> V2:
Removed qemu_mutex_destroy().
---
target-arm/cpu.c | 14 ++
target-arm/cpu.h | 3 +++
target-arm/helper.h
17 matches
Mail list logo
