qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 17/38] aie: add target helpers


From: Alex Bennée
Subject: Re: [Qemu-devel] [RFC 17/38] aie: add target helpers
Date: Mon, 21 Sep 2015 21:59:03 +0100
User-agent: mu4e 0.9.12; emacs 24.5.50.4

Paolo Bonzini <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]