FEX 2409 Highlights Some Of The Challenges Of Emulating x86 On RISC-V

[stormcrow]

Those ARM kernel maintainers are probably a cabal financed by vendors of CPUs without TSO.

The solutions to their problems is simple: if an application requests PR_SET_MEM_MODEL_TSO, and the request fails, then the kernel should pin that application (all of its threads) to a single CPU core. That has the effect of enforcing sequentional memory ordering, which is the strictest order of them all.

The reason why no one mentioned that simple solution is probably because all kernel developers wanted to protect the CPU manufacturers who are financing the kernel development.

I can't believe that no one thought of such a simple solution.

... because it would murder performance...

Also, no need to resort to vile conspiracy theories. There's more than enough architecture zealots out there enamored with the purity of their Chosen One to look no further than "Ew, x86 memory management! Kill it with fire!" The rest of it is just the same "I won't support it" inertia that apparently forget the Linux kernel isn't their ball to play keep away with.

[stormcrow]

Insightful answers, everyone. Thanks for explaining and clarifying things. 👍🏽

So if I understand correctly, TSO support would be feasible and useful to implement in a RISC-V extension, whereas flags are inherently against the very philosophy of the RISC-V architecture.

But @Uiop, your statement that "emulation of flags does not incur a high performance penalty" seems to run counter to what is claimed in the blog post: "By contrast, architectures like RISC-V lack flags, slowing down x86-on-RISC-V emulators." Or is it actually possible to minimize such slowdowns to negligible levels (compared for for instance ARM) through proper optimization of emulation code?

I might additionally point out that there was a recent argument on the LKML about the TSO in Apple's and others' most current Arm CPUs. Some of the devs were unreasonably and solidly against picking TSO support up in the Linux kernel for fear of it becoming an indefinite crutch for porting x86 code to native Arm (which is the entire point of the extension). Some Arm purists were arguably unreasonable about supporting it without articulating technical objections.

So far as I know, regardless of some Arm CPUs having hardware TSO, the upstream Linux kernel tree doesn't have support for it and probably won't till the current crop of maintainers are either pushed out or retire. For now it'll have to be carried externally by Asahi or other distros that pick it up. Probably going to become an increasing pressure point as more Arm CPUs pick up TSO to be able to run software written to support x86's peculiar memory system.

Summary of the argument covered by LWN is here: https://lwn.net/Articles/970907/

[hotaru]

So if I understand correctly, TSO support would be feasible and useful to implement in a RISC-V extension,

not only is it feasible, it already exists.

and there's also a dynamic TSO extension.

[spiritofreason]

But @Uiop, your statement that "emulation of flags does not incur a high performance penalty" seems to run counter to what is claimed in the blog post: "By contrast, architectures like RISC-V lack flags, slowing down x86-on-RISC-V emulators." Or is it actually possible to minimize such slowdowns to negligible levels (compared for for instance ARM) through proper optimization of emulation code?

From the perspective of the RISC-V project, there is some backwards thinking here, hehe. Optimizing the RISC-V architecture to emulate x86 would be the antithesis of the project. RISC-V aims to achieve high performance computation of software that is natively compiled for its ISA (while making the ISA optimal for hardware implementation, determined via PPA metrics). It wants to do well at computing at the final layer of abstraction, if you will.

Meanwhile, x86 as an intermediate layer makes for a huge (and arguably very crappy) interface. Since RISC-V is explicitly not going to shove a bunch of junk into the ISA that hardware must implement at significant cost, supporting it becomes software's job. Now you can think of x86 as a shitty, inefficient software library instead

This makes it unfortunate for x86 programs that will never be recompiled, like old games, but you don't get the benefits of a clean ISA if you start bending over backwards to support other ISAs. Instead, extensions would need to be demonstrably useful and efficient for actually computing final outputs.

[SteamPunker]

Insightful answers, everyone. Thanks for explaining and clarifying things. 👍🏽

So if I understand correctly, TSO support would be feasible and useful to implement in a RISC-V extension, whereas flags are inherently against the very philosophy of the RISC-V architecture.

But @Uiop, your statement that "emulation of flags does not incur a high performance penalty" seems to run counter to what is claimed in the blog post: "By contrast, architectures like RISC-V lack flags, slowing down x86-on-RISC-V emulators." Or is it actually possible to minimize such slowdowns to negligible levels (compared for for instance ARM) through proper optimization of emulation code?

[discordian]

So then would it be possible to define another extension for RISC-V, specifically for hardware-assisting x86 emulation, by adding optional support for such flags, as well as the TSO memory model that Apple also added to the M1 to speed up x86 emulation?

those flags are a nightmare when it comes to designing hardware. there is a conscious decision to not use them, and adding them is not an isolated "extension" but you would need to add a hidden "flags" register dependency thorough the dispatch. If there are flags they should be tied to the output register.
it's what truly makes RISC RISC - not the count of instructions but a simple orthogonally extensible isa without such complications.

[ahrs]

So then would it be possible to define another extension for RISC-V, specifically for hardware-assisting x86 emulation, by adding optional support for such flags, as well as the TSO memory model that Apple also added to the M1 to speed up x86 emulation?

Then just wait 10 or 20 years for this extension to surface in the already non-existent hardware

[SteamPunker]

So then would it be possible to define another extension for RISC-V, specifically for hardware-assisting x86 emulation, by adding optional support for such flags, as well as the TSO memory model that Apple also added to the M1 to speed up x86 emulation?

[LinAGKar]

FEX 2409 Highlights Some Of The Challenges Of Emulating x86 On ARM rather, since RISC-V is only mentioned as an aside.

[phoronix]

Phoronix: FEX 2409 Highlights Some Of The Challenges Of Emulating x86 On RISC-V

FEX 2409 has been released for this open-source project that's known for allowing x86_64 Linux binaries -- including both games and applications -- to run rather well on AArch64. It's also been working on enabling x86_64 programs on RISC-V but there due to architectural differences it's more of a challenge than with ARM...

https://www.phoronix.com/news/FEX-2409-Emulator