Re: Rust in Qemu BoF followup: Rust vs. qemu platform support

[David Gibson]

On Fri, Sep 17, 2021 at 10:04:50AM -0600, Warner Losh wrote:
> On Fri, Sep 17, 2021 at 5:35 AM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> 
> > 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

That's another good point.  For the architectures with multiple
variants / editions, we should clarify on
https://qemu-project.gitlab.io/qemu/about/build-platforms.html which
ones we support as well: riscv32 vs. riscv64, sparcv8 vs. sparcv9,
armv6 vs armv7 vs aarch64, etc.

> 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.

I've updated my table entry to N/A on that basis.  Thanks for the
clarification, this wasn't obvious to me from
https://www.freebsd.org/platforms/ (it says "Tier 4", without
explaining what that means).

> 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.

Ok.  That one has Tier3* support in Rust, which is probably good
enough for the informal tier of support it has in qemu.

> So it all depends on what having rust means for those platforms that don't
> have
> it.

Well, working out what we can do with that is kind of the point of
constructing this matrix.

> 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 :).

I'd say the "half a loaf" situation is pretty much going ahead
regardless.  Whether we're willing to go ahead with making Rust
mandatory for the basic build is an open question, which this analysis
is largely about answering.

> 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...

Might be worth talking to the Rust people as well, to see if you can
get a promotion from Tier3 to Tier2.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature