[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
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., (continued)
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/17
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Peter Maydell, 2014/12/17
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Peter Maydell, 2014/12/17
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Alexander Graf, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Dr. David Alan Gilbert, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Paolo Bonzini, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Alexander Graf, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*.,
Mark Burton <=
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Alexander Graf, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Paolo Bonzini, 2014/12/18
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Mark Burton, 2014/12/17
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Dr. David Alan Gilbert, 2014/12/17
- Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*., Peter Maydell, 2014/12/17