> On 18 Dec 2014, at 15:44, Alexander Graf <ag...@suse.de> 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
