Well, all I can tell you is that I've run the tests and they work. If you want to setup more cross-arch tests, then I can, or you can do downstream checks in Fedora with Packit.

For what's worth it, I test both these platforms (as well as 386 for 32-bit and s390x for big endian) at ncruces/go-sqlite3 with Qemu.

The interpreter should be fine, but WASI is completely untested. Given it's Linux, the bar shouldn't be too high to get things working, though. The major issue here is that the structs need to have the same layout (which is not a given across archs).

I'm of the opinion that, at least the WASI implementation, if it's not spun off, should start using x/sys/unix to take these matters as much as possible off our hands.

Techaro has a PPC64LE shellbox, email me if you want access.

FYI there is now also https://github.com/IBM/actionspz (e.g. see https://github.com/IBM/actionspz/blob/main/docs/FAQ.md#can-i-specify-the-ibm-hardware-to-execute-my-workflow-on)

dylibso/chicory is running some tests there

For Linux we probably just use docker/setup-qemu-action and run a subset of tests. I regularly test wazero that way. In the past I think we didn't do that because of concerns about quotas? What's the situation now?

Another solution for this is to simply depend on x/sys/unix: push the responsibility there, and assume things should work if they're tested on Linux/macOS/BSD.

This would be a breaking change with the "zero dependencies" motto, but: Go maintainers maintain x/sys/unix, and it's their stated goal that syscalls should go through there.