Multithreaded TCG of x86_64/i386

[sceptical-coder]

This one implies that subject should be possible since qemu 3.1. Is that true?

[osy]

It is implemented as Force Multicore.

[sceptical-coder]

But is the comment about incorrect emulation correct?

[sceptical-coder]

And well, specifically, about x86 memory model being unsupported on ARM?

[professorUnknown]

Give him the link

[sceptical-coder]

Give him the link

Whom did you meant? If that’s to me, then I’m referring to quite a hope-giving response of the bug I linked to earlier: https://bugs.launchpad.net/qemu/+bug/1735049/comments/1

[osy]

I did find the commit they referenced qemu/qemu@b32dc3370a

[osy]

So yeah in theory it should work but I'm confused because this piece of code exists in QEMU

/*
 * 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)

[osy]

Yeah someone should contact the QEMU developer for clarification because the above code will default x86 on ARM64 to disable MTTCG. And we know from experience that forcing MTTCG results in random issues.

[professorUnknown]

https://www.qemu.org/support/ you can check out their mailing list

[osy]

@professorIsaac yeah I think we all know what it means to contact

[professorUnknown]

I will do it

[sceptical-coder]

@professorIsaac yeah I think we all know what it means to contact

Ahm, is that some sort of inside knowledge? Could you please enlighten me about that well, supposed skepticism about contacting QEMU devs?

[professorUnknown]

In short they explained to me that since the host arm64 is a weaker memory order than the guest x86 they disabled mttcg because if they would implement it would slow everything down but the good news is that if the guest is the same memory order it is not disabled and if it is weaker memory order it is not disabled also.

[osy]

Right, that's what I figured from the code. So basically the launchpad comment was incorrect. There is no MTTCG support for x86 on ARM64.

[jkleckner]

I found it intriguing that Apple added support for x86 memory ordering to the M1 CPU.

[osy]

Unfortunately there’s no public APIs for that yet. @saagarjha did you ever manage to benchmark the performance and see if it’s worth implementing?

[saagarjha]

TSO’s overhead is something like 20% for most applications, tending towards 50% if you hit contended memory a lot.

[jkleckner]

TSO’s overhead is something like 20% for most applications, tending towards 50% if you hit contended memory a lot.

For my Win10 x86_64 vm on Apple Silicon, 20% would be more than made up for with being able to use 8 cores.
How would TSO be enabled? Is the missing public API the blockage?

FYI, here are some tangential links:

• https://gitlab.com/qemu-project/qemu/-/issues/?search=mttcg&sort=created_date&state=all&first_page_size=20
• https://gitlab.com/qemu-project/qemu/-/issues/?label_name%5B%5D=accel%3A%20TCG
• https://wiki.qemu.org/Features/tcg-multithread
• https://developer.apple.com/documentation/virtualization/running_intel_binaries_in_linux_vms_with_rosetta
• https://arstechnica.com/gadgets/2022/06/macos-ventura-will-extend-rosetta-support-to-linux-virtual-machines/
• https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code#Synchronize-Access-to-Shared-Data-in-Memory
• https://www.cs.utexas.edu/~bornholt/post/memory-models.html
• https://en.wikipedia.org/wiki/Memory_ordering

[jkleckner]

Adding a cross link to the trollstore ios code PR: #4866