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 ;)


Alex

Reply via email to