Re: [Qemu-devel] [RFC v1 12/12] cpus: default MTTCG to on for 32 bit ARM on x86

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> On 15 April 2016 at 15:23, Alex Bennée <address@hidden> wrote:
>> This makes multi-threading the default for 32 bit ARM on x86. It has
>> been tested with Debian Jessie as well as my extended KVM unit tests
>> which stress the SMC and TB invalidation code. Those tests can be found
>> at:
>>
>>   https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v5
>>
>> Signed-off-by: Alex Bennée <address@hidden>
>> ---
>>  cpus.c | 20 ++++++++++++++++----
>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/cpus.c b/cpus.c
>> index 860e2a9..daa92c7 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -171,12 +171,24 @@ opts_init(tcg_register_config);
>>
>>  static bool default_mttcg_enabled(void)
>>  {
>> -    /*
>> -     * TODO: Check if we have a chance to have MTTCG working on this 
>> guest/host.
>> -     *       Basically is the atomic instruction implemented? Is there any
>> -     *       memory ordering issue?
>> +    /* Checklist for enabling MTTCG on a given frontend/backend combination
>> +     *
>> +     *  - Are atomics correctly modelled for an MTTCG environment
>> +     *  - If the backend is weakly ordered
>> +     *    - has the front-end implemented explicit memory ordering ops
>> +     *    - does the back-end generate code to ensure memory ordering
>>       */
>> +#if defined(__i386__) || defined(__x86_64__)
>> +    /* x86 backend is strongly ordered which helps a lot */
>> +    #if defined(TARGET_ARM)
>> +    return true;
>> +    #else
>> +    return false;
>> +    #endif
>> +#else
>> +    /* Until memory ordering implemented things will likely break */
>>      return false;
>> +#endif
>
> No new per-host ifdef ladders, please (or per-target ifdef ladders,
> either). Have some #defines for "TCG backend supports MTTCG" and
> "TCG frontend supports MTTCG" which get set in some suitable per-host
> and per-target header, and only enable if they're both set.

Will do so. I guess the middling case of backend is strongly ordered
enough to get away with partial barrier implementation at the front end
should be skipped? We'll only turn on the frontend/backend support flags
when:

  * All frontends fully express the ordering constraints to the TCG
    (e.g. all barriers and annotations complete)

  * The backend emits enough code to ensure any ordering constraint
    expressed in TCG ops can be satisfied.

Are you happy to keep the commentary here with the default function as
that is where people are likely to end up when searching?

>
> thanks
> -- PMM


--
Alex Bennée