Re: [Qemu-devel] [PATCH v7 05/27] tcg: add options for enabling MTTCG

[Pranith Kumar <bobby.prani@gmail.com>]

Alex Bennée writes:

> From: KONRAD Frederic <fred.konrad@greensocs.com>
>
> We know there will be cases where MTTCG won't work until additional work
> is done in the front/back ends to support. It will however be useful to
> be able to turn it on.
>
> As a result MTTCG will default to off unless the combination is
> supported. However the user can turn it on for the sake of testing.
>

<snip>

>  static TimersState timers_state;
> +bool mttcg_enabled;
> +
> +/*
> + * We default to false if we know other options have been enabled
> + * which are currently incompatible with MTTCG. Otherwise when each
> + * guest (target) has been updated to support:
> + *   - atomic instructions
> + *   - memory ordering primitives (barriers)
> + * they can set the appropriate CONFIG flags in ${target}-softmmu.mak
> + *
> + * Once a guest architecture has been converted to the new primitives
> + * there are two remaining limitations to check.
> + *
> + * - The guest can't be oversized (e.g. 64 bit guest on 32 bit host)
> + * - The host must have a stronger memory order than the guest
> + *
> + * It may be possible in future to support strong guests on weak hosts
> + * but that will require tagging all load/stores in a guest with their
> + * implicit memory order requirements which would likely slow things
> + * down a lot.
> + */
> +
> +static bool check_tcg_memory_orders_compatible(void)
> +{
> +#if defined(TCG_DEFAULT_MO) && defined(TCG_TARGET_DEFAULT_MO)
> +    return (TCG_DEFAULT_MO & ~TCG_TARGET_DEFAULT_MO) == 0;

I am not sure this is what we intended. If the guest is weaker than the host,
we can still run the guest if we translate the guest barriers. With the above,
a strong host cannot run a weaker host.

I think what we want is to disallow weak hosts from running stronger guests,
since we do not enforce the implicit ordering semantics of the guest as of
now.  In that case you can filter them out using the following:

TCG_DEFAULT_MO | (TCG_DEFAULT_MO ^ ~TCG_TARGET_DEFAULT_MO) == TCG_MO_ALL

We want our guest execution to prevent all possible re-ordering. The first
term above is the host memory order. If the host is SC, we do not need to
check anything else. If not, the second term tells us the difference in
ordering between the guest and the host. It gives the kind of barriers
which will be translated from guest to host. Both these together should cover
all the cases for the memory order to be compatible.

Thoughts?

Thanks,
--
Pranith