Paolo Bonzini <pbonz...@redhat.com> writes:
> On 24/08/2015 02:23, Emilio G. Cota wrote:
>> +void HELPER(aie_st_pre)(CPUArchState *env, target_ulong vaddr)
>> +{
>> + if (unlikely(env->aie_lock_enabled)) {
>> + if (env->aie_locked) {
>> + return;
>> + }
>
> Now that I've reviewed your code more carefully, the approach you're
> using looks more promising than I thought. There are advantages over
> Alvise's code, namely:
>
> - cache-line vs. page granularity
There is nothing that stops Alvise's slow-path helpers having a better
granularity when deciding if the exclusive flag needs tripping. However
I like the lookup approach in these patches.
> - avoiding the global TLB flush (due to the virtually indexed TLBs)
>
> - easy support for user-mode emulation
>
> and some of the disadvantages look more easily fixable than I thought,
> too (e.g. TLB entry bloat).
>
> The main advantage of Alvise's code, on the other hand, is the minimal
> overhead when there are no active LL/SC combinations and the better
> integration with TCG.
I too prefer the expression of LL/SC semantics via TCG ops.
> A random idea: would it be possible to move some of the helper code to
> generated TCG code? For example, maintaining a count of outstanding
> load-locked operations and forcing the slow path for stores if it is
> non-zero?
>
> Paolo
>
>> + aie_st_lock_ret(env, vaddr, GETRA());
>> + } else {
>> + hwaddr paddr = h_get_st_phys(env, vaddr, GETRA());
>> +
>> + if (unlikely(aie_entry_exists(paddr))) {
>> + h_aie_lock(env, paddr);
>> + }
>> + }
>> +}
--
Alex Bennée
