qemu-devel
[Top][All Lists]
Advanced

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

Re: Clarification of above code


From: Oliver Christopher
Subject: Re: Clarification of above code
Date: Sun, 12 Apr 2020 16:55:56 -0400

Thank you for the clarification.

On Sun, Apr 12, 2020 at 4:54 PM Peter Maydell <address@hidden> wrote:
On Sun, 12 Apr 2020 at 21:46, Oliver Christopher <address@hidden> 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

reply via email to

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