Clarification of above code

Clarification of above code

[Oliver Christopher]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

/* * 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_GUEST_DEFAULT_MO) && defined(TCG_TARGET_DEFAULT_MO)
    return (TCG_GUEST_DEFAULT_MO & ~TCG_TARGET_DEFAULT_MO) == 0;
#else
    return false;
#endif
}

That function will return false for x86_64 on ARM64.

On tcg/aarch64/tcg-target.h

#define TCG_TARGET_DEFAULT_MO (0)

On target/i386/cpu.h

/* The x86 has a strong memory model with some store-after-load re-ordering */
#define TCG_GUEST_DEFAULT_MO      (TCG_MO_ALL & ~TCG_MO_ST_LD)

I am asking for clarification because the above code will default x86 on
ARM64 to disable MTTCG.

[-- Attachment #2: Type: text/html, Size: 7264 bytes --]

Re: Clarification of above code

[Peter Maydell]

On Sun, 12 Apr 2020 at 21:46, Oliver Christopher <adultjiuice@gmail.com> wrote:
>
> /*
>  * 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.
>  */

> I am asking for clarification because the above code will default
> x86 on ARM64 to disable MTTCG.

What clarification are you after? The comment says we won't
enable MTTCG if the host has a weaker memory model than
the guest; arm64 has a weaker memory model than x86,
and so we don't enable MTTCG for x86 guest on arm64 host.
The 'it may be possible' paragraph explains why MTTCG
on this combination would be tricky.

(Strictly the comment should say "host must have at least as
strong a memory order as the guest", but that makes no difference
in the case you're asking about.)

thanks
-- PMM

Re: Clarification of above code

[Oliver Christopher]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

Thank you for the clarification.

On Sun, Apr 12, 2020 at 4:54 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Sun, 12 Apr 2020 at 21:46, Oliver Christopher <adultjiuice@gmail.com>
> wrote:
> >
> > /*
> >  * 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.
> >  */
>
> > I am asking for clarification because the above code will default
> > x86 on ARM64 to disable MTTCG.
>
> What clarification are you after? The comment says we won't
> enable MTTCG if the host has a weaker memory model than
> the guest; arm64 has a weaker memory model than x86,
> and so we don't enable MTTCG for x86 guest on arm64 host.
> The 'it may be possible' paragraph explains why MTTCG
> on this combination would be tricky.
>
> (Strictly the comment should say "host must have at least as
> strong a memory order as the guest", but that makes no difference
> in the case you're asking about.)
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 2292 bytes --]