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

[Alexander Graf]

On 18.12.14 15:51, Mark Burton wrote:
> 
>> 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’…?

Yeah, the semantics should be tied to what TM would give you. We can
always be more safe than TM in our fallback implementation, but I
wouldn't want to see semantic optimizations tied to the MMIO
implementation put in.

This is mostly theory though, try to write the code and see where things
fall apart, then we'll be in a much better position to rationalize on
where to do things differently.


Alex