[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 01/10] target-arm: protect cpu_exclusive_*.
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [RFC 01/10] target-arm: protect cpu_exclusive_*. |
Date: |
Fri, 27 Feb 2015 07:56:44 +0900 |
On 27 February 2015 at 03:09, Frederic Konrad <address@hidden> wrote:
> On 29/01/2015 16:17, Peter Maydell wrote:
>>
>> On 16 January 2015 at 17:19, <address@hidden> wrote:
>>>
>>> From: KONRAD Frederic <address@hidden>
>>>
>>> This adds a lock to avoid multiple exclusive access at the same time in
>>> case of
>>> TCG multithread.
>> All the same comments I had on this patch earlier still apply:
>>
>> * I think adding mutex handling code to all the target-*
>> frontends rather than providing facilities in common
>> code for them to use is the wrong approach
>> * You will fail to unlock the mutex if the ldrex or strex
>> takes a data abort
>> * 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
>> host environment which is used by both softmmu and useronly
>> configs
> We decided to implement the whole atomic instruction inside an helper
...which is a different approach which still isn't really
addressing any of my remarks in the list above...
> but is
> that
> possible to get the data with eg: cpu_physical_memory_rw instead of the
> normal
> generated code?
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 a
tlb miss!)
> One other thing which looks suspicious it seems there is one pair of
> exclusive_addr/exclusive_val per CPU is that normal?
Pretty sure we've already discussed how the current ldrex/strex
implementation is not architecturally correct. I think this is
another of those areas.
In general I'd be much happier seeing a proper sketch of your
design, what data structures etc you intend to share between
CPUs and which are per-CPU, what generic mechanisms you plan
to provide to allow targets to implement atomic instructions, etc.
It's quite hard to see the whole picture at the moment.
-- PMM