On Fri, Sep 17, 2021 at 06:58:37PM +1000, David Gibson wrote:
> Hi all,
>
> At the qemu-in-rust BoF at KVM Forum, I volunteered to look into
> whether Rust supported all the host/build platforms that qemu does,
> which is obviously vital if we want to make Rust a non-optional
> component of the build.
>
> I've added the information to our wiki at:
> https://wiki.qemu.org/RustInQemu
>
> TBH, the coverage is not as good as I expected. Linux, macOS and
> Windows are pretty much ok, with the exception of Linux on Sparc.
> There are a lot of gaps in *BSD support, however.
To me the coverage looks pretty much what I'd expect to need
for QEMU - almost all boxes that I'd want to see green are
green, except OpenBSD, possibly x86 32-bit for *BSD and
sparc(64) on Linux.
Mostly it highlights that we've never explicitly declared what
our architecture coverage is intended to be. We do check host
arches in configure, but we didn't distinguish this by OS and
I think that's a mistake.
In terms of our CI coverage, the only non-x86 testing we do
is for Linux based systems.
Although its possible people use non-x86 on non-Linux, I don't
recall any discussions/bugs/patches targetting this situation,
so if we do have users I doubt there's many.
Would be interesting to hear input from anyone representing
interests of the various *BSD platforms about their thoughts
wrt non-x86 coverage.
I think our first step is probably to make our architecture
support explicit, regardless of our use of Rust.
If we assume QEMU followed a similar 3 tier policy, on the QEMU
side my interpretation of what we're implicitly targetting would
be:
Linux: all arches with a TCG target
macOS: x86_64
Windows: i686, x86_64
FreeBSD: x86_64 (maybe +i686 too)
NetBSD: x86_64 (maybe +i686 too)
OpenBSD: x86_64 (maybe +i686 too)
with tier 1 vs 2 for the above depending on whether we run
'make check' in gating CI)
wrt FreeBSD:
The main focus of the project is on AMD64 (x86_64) and ARM64 (aarc64). With
ricsv64 being ascendant as well. i386 and armv7 are fading. ppc64 has strong,
but episodic, interest as well. The rest are bit players.
i386 (i686 really), armv7 and riscv7 are the next tier of interest in FreeBSD
land. i386 is confined to 32-bit VMs with only a few legacy hardware deployments
still kicking. armv7 is more popular on embedded boards, some of which have
a need to run qemu. riscv64 has a rust port that's being upstreamed, but not
there yet and there's likely interest to run qemu on it for research projects.
riscv64 isn't widely deployed but has a lot of developer interest / mindshare.
sparc64 was removed from FreeBSD 13 and has been irrelevant for years.
ppc 32 bit has some minor interest. mips has been fading fast and stands
an excellent chance of being removed before FreeBSD 14 (which is currently
slated for 2022). PowerPC 64 is hard to talk about... there's interest that comes
and goes, but when it's around, it's quite intense. It's quite likely there will
be interest to run qemu on ppc64 on FreeBSD, but that's much less certain.
So it all depends on what having rust means for those platforms that don't have
it. Would it be a 'half a loaf' situation where the non-rust bits would be buildable
but cool new drivers written in rust won't be? Or will it be so central that rust is
table stakes to even start a qemu build? To be honest, I'm not sure this difference
would greatly affect the above answer :).
Rust works really well on x86_64 and aarch64 (though there's more often a lag
on the latter of a few weeks). I know of a rust riscv64 port, but that's just getting
ready to upstream. No first-hand or second-hand clue on the rest.
FreeBSD tl;dr: x86_64 and aarch64 are must have. i386, armv7 and riscv64 are
really nice to have. ppc64 might also be in that list, but that's less certain. The rest
have little to no relevance.
Warner
P.S I've been poking at people to get our QEMU aarch64 CI story in better
shape than it is today... I'll have to continue to prompt those interested...