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

[David Gibson]

On Fri, Sep 17, 2021 at 12:34:29PM +0100, Daniel P. Berrangé 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.

I agree.  Currently
https://qemu-project.gitlab.io/qemu/about/build-platforms.html lists
build OSes and build architectures separately, which kind of implies
the full matrix - but I don't think we really want to support that, so
I think we should pin this down more precisely.

> 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

+ aarch64, since that's on the way.

>  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)
> 
> That isn't to say that other combinations don't work, but if they
> did work, they would be at most Tier 3 from QEMU's POV.

Makes sense to me.

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