qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*.


From: Mark Burton
Subject: Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*.
Date: Thu, 18 Dec 2014 15:51:35 +0100

> On 18 Dec 2014, at 15:44, Alexander Graf <address@hidden> wrote:
> 
> 
> 
> On 18.12.14 15:20, Mark Burton wrote:
>> 
>> 
>>> On 18/12/2014 13:24, Alexander Graf wrote:
>>>> That's the nice thing about transactions - they guarantee that no other
>>>> CPU accesses the same cache line at the same time. So you're safe
>>>> against other vcpus even without blocking them manually.
>>>> 
>>>> For the non-transactional implementation we probably would need an "IPI
>>>> others and halt them until we're done with the critical section"
>>>> approach. But I really wouldn't concentrate on making things fast on old
>>>> CPUs.
>>> 
>>> The non-transactional implementation can use softmmu to trap access to
>>> the page from other VCPUs.  This makes it possible to implement (at the
>>> cost of speed) the same semantics on all hosts.
>>> 
>>> Paolo
>> 
>> I believe what your describing, using transactional memory, or using softmmu 
>> amounts to either option 3 below or option 4.
>> Relying on it totally was option 4. 
>> 
>> Seems to me, the problem with that option is that support for some hosts 
>> will be a pain, and covering everything will take some time :-(
>> 
>> Option 3 suggests that we build a ‘slow path’ mechanism first - make sure 
>> that works (as a backup), and then add optimisations for specific 
>> hosts/guests afterwards. To me that still seems preferable?
> 
> Yes, the only thing I'm in favor for here is to align the semantics with
> what transactional memory would give you. That way moving to the fast
> implementation will be easy and people would actually want to use
> multi-threaded TCG ;)

In other words — the back-end (slow path) memory interface should look 
‘transactional’…?

Cheers

Mark.




> 
> 
> Alex


         +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210

        +33 (0)603762104
        mark.burton




reply via email to

[Prev in Thread] Current Thread [Next in Thread]