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

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

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.

I've included some notes on where the information comes from, and some
uncertainties in there.

I've made an effort to get the information correct, but double
checking would be appreciated.

I haven't yet looked into the packaging situation for the Rust
toolchain on various platforms and distros, but I still intend to do
so.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Cornelia Huck]

On Fri, Sep 17 2021, David Gibson <david@gibson.dropbear.id.au> 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

Thank you for doing that!

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

Yes :(

Do we actually have an idea what we would require? I'm surprised that
there are so many targets without host tools or without std support (but
maybe they are only missing small things.)

>
> I've included some notes on where the information comes from, and some
> uncertainties in there.
>
> I've made an effort to get the information correct, but double
> checking would be appreciated.

I did not spot any errors on a quick cross check, but I'm not really
sure about what the BSDs support.

>
> I haven't yet looked into the packaging situation for the Rust
> toolchain on various platforms and distros, but I still intend to do
> so.

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

Hi

On Fri, Sep 17, 2021 at 1:19 PM Cornelia Huck <cohuck@redhat.com> wrote:

> On Fri, Sep 17 2021, David Gibson <david@gibson.dropbear.id.au> 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
>
> Thank you for doing that!
>
>
Yes, the condensed coloured matrix is much more readable than the Rust long
list. I wonder if they would also adopt it :)


> >
> > 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.
>
> Yes :(
>

Can we say reasonably that QEMU is supported on *BSD other than x86 (and
aarch64?), I wonder. Maybe we should consider moving those under the
unsupported rank.


>
> Do we actually have an idea what we would require? I'm surprised that
> there are so many targets without host tools or without std support (but
> maybe they are only missing small things.)
>

For sparc 32, it was added to support Gentoo at that time which didn't
switch to 64-bit yet (https://github.com/rust-lang/rust/pull/48297)

For the past 2-3y, Gentoo sparc is now 64 bit. (like Debian apparently for
a while)

But apparently, by lack of CI it was downgraded to Tier-3.

Is it reasonable to officially drop support for sparc 32 in QEMU too?


> >
> > I've included some notes on where the information comes from, and some
> > uncertainties in there.
> >
> > I've made an effort to get the information correct, but double
> > checking would be appreciated.
>
> I did not spot any errors on a quick cross check, but I'm not really
> sure about what the BSDs support.
>
> >
> > I haven't yet looked into the packaging situation for the Rust
> > toolchain on various platforms and distros, but I still intend to do
> > so.
>
>
>
I would share our wiki page on r/rust if you don't mind, as there are
various people that can help us fill the gaps I think.

Thanks

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 3675 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3596 bytes --]

On Fri, Sep 17, 2021 at 01:54:22PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Fri, Sep 17, 2021 at 1:19 PM Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Fri, Sep 17 2021, David Gibson <david@gibson.dropbear.id.au> 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
> >
> > Thank you for doing that!
> >
> >
> Yes, the condensed coloured matrix is much more readable than the Rust long
> list. I wonder if they would also adopt it :)

So, in this case we have the relatively small matrix of qemu supported
build OSes by qemu supported build ISAs.  For the Rust page there's a
much larger list of OSes, and a somewhat larger list of ISAs.  Or
larger still since it's really ABIs they're listing there rather than
just ISAs.  And lots of that matrix would be missing for all the OSes
that only support a handful of ISAs.  So I think trying to do it as a
matrix there would get pretty unwieldy.

> > > 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.
> >
> > Yes :(
> 
> Can we say reasonably that QEMU is supported on *BSD other than x86 (and
> aarch64?), I wonder. Maybe we should consider moving those under the
> unsupported rank.

Yeah, that was my first question as well.  I included it all since the
qemu page doesn't qualify the list of OSes/archs, but I did wonder if
anyone is really using obscure archs with a BSD.

> > Do we actually have an idea what we would require? I'm surprised that
> > there are so many targets without host tools or without std support (but
> > maybe they are only missing small things.)
> 
> For sparc 32, it was added to support Gentoo at that time which didn't
> switch to 64-bit yet (https://github.com/rust-lang/rust/pull/48297)
> 
> For the past 2-3y, Gentoo sparc is now 64 bit. (like Debian apparently for
> a while)
> 
> But apparently, by lack of CI it was downgraded to Tier-3.
> 
> Is it reasonable to officially drop support for sparc 32 in QEMU
> too?

As a qemu build arch I would say probably yes.  As a qemu *target*
arch, probably not.  Qemu targets aren't really relevant to this
discussion, but I'm clarifying since if someone sees "XXX arch support
in qemu" without context they'll probably think of target arch before
host arch.

> > > I've included some notes on where the information comes from, and some
> > > uncertainties in there.
> > >
> > > I've made an effort to get the information correct, but double
> > > checking would be appreciated.
> >
> > I did not spot any errors on a quick cross check, but I'm not really
> > sure about what the BSDs support.
> >
> > >
> > > I haven't yet looked into the packaging situation for the Rust
> > > toolchain on various platforms and distros, but I still intend to do
> > > so.
> >
> >
> >
> I would share our wiki page on r/rust if you don't mind, as there are
> various people that can help us fill the gaps I think.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Richard Henderson]

On 9/17/21 4:03 AM, David Gibson wrote:
>> For sparc 32, it was added to support Gentoo at that time which didn't
>> switch to 64-bit yet (https://github.com/rust-lang/rust/pull/48297)
>>
>> For the past 2-3y, Gentoo sparc is now 64 bit. (like Debian apparently for
>> a while)
>>
>> But apparently, by lack of CI it was downgraded to Tier-3.
>>
>> Is it reasonable to officially drop support for sparc 32 in QEMU
>> too?
> 
> As a qemu build arch I would say probably yes.

We dropped host support for sparcv8 (true 32-bit) a long time ago.
We only support sparcv9 in ilp32 (sparcv8plus) and lp64 (sparc64).

I'd be happy top drop sparcv8plus as well, because I haven't been able to test it for 
something like 2-3 years.


r~

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Sat, Sep 18, 2021 at 01:01:35PM -0700, Richard Henderson wrote:
> On 9/17/21 4:03 AM, David Gibson wrote:
> > > For sparc 32, it was added to support Gentoo at that time which didn't
> > > switch to 64-bit yet (https://github.com/rust-lang/rust/pull/48297)
> > > 
> > > For the past 2-3y, Gentoo sparc is now 64 bit. (like Debian apparently for
> > > a while)
> > > 
> > > But apparently, by lack of CI it was downgraded to Tier-3.
> > > 
> > > Is it reasonable to officially drop support for sparc 32 in QEMU
> > > too?
> > 
> > As a qemu build arch I would say probably yes.
> 
> We dropped host support for sparcv8 (true 32-bit) a long time ago.
> We only support sparcv9 in ilp32 (sparcv8plus) and lp64 (sparc64).

We really need to update
https://qemu-project.gitlab.io/qemu/about/build-platforms.html
to clarify this then.  I don't really know what the procedures are for
updating the website.

> I'd be happy top drop sparcv8plus as well, because I haven't been able to
> test it for something like 2-3 years.

Sounds like a reasonable reason.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Maydell]

On Mon, 20 Sept 2021 at 06:07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sat, Sep 18, 2021 at 01:01:35PM -0700, Richard Henderson wrote:
> > We dropped host support for sparcv8 (true 32-bit) a long time ago.
> > We only support sparcv9 in ilp32 (sparcv8plus) and lp64 (sparc64).
>
> We really need to update
> https://qemu-project.gitlab.io/qemu/about/build-platforms.html
> to clarify this then.  I don't really know what the procedures are for
> updating the website.

It's automatically updated by building the documentation from current
head-of-git, so the answer is "submit a patch to change
docs/about/build-platforms.rst". (That's a pretty new file, and
the stuff about CPU architectures has gone in only very recently,
so it's not unsurprising if Marc-André and I got some things wrong:
we were just looking through tcg/ to see what it seemed to have
support for.)

The structure of the build-platforms page currently assumes that
"supported host CPU architectures" and "supported host OSes" are
basically orthogonal, because historically the nature of QEMU has
been that this is more-or-less true. If we want to try to be more
specific about that then we'd need to re-jig things.

-- PMM

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On Mon, Sep 20, 2021 at 09:13:44AM +0100, Peter Maydell wrote:
> On Mon, 20 Sept 2021 at 06:07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Sat, Sep 18, 2021 at 01:01:35PM -0700, Richard Henderson wrote:
> > > We dropped host support for sparcv8 (true 32-bit) a long time ago.
> > > We only support sparcv9 in ilp32 (sparcv8plus) and lp64 (sparc64).
> >
> > We really need to update
> > https://qemu-project.gitlab.io/qemu/about/build-platforms.html
> > to clarify this then.  I don't really know what the procedures are for
> > updating the website.
> 
> It's automatically updated by building the documentation from current
> head-of-git, so the answer is "submit a patch to change
> docs/about/build-platforms.rst". (That's a pretty new file, and
> the stuff about CPU architectures has gone in only very recently,
> so it's not unsurprising if Marc-André and I got some things wrong:
> we were just looking through tcg/ to see what it seemed to have
> support for.)

Oh.. yeah.. that's pretty obvious now I look at it </sheepish>

> 
> The structure of the build-platforms page currently assumes that
> "supported host CPU architectures" and "supported host OSes" are
> basically orthogonal, because historically the nature of QEMU has
> been that this is more-or-less true. If we want to try to be more
> specific about that then we'd need to re-jig things.

Yeah, I think we kind of need to do that.  Even apart from the Rust
support thing, I think it would help to clarify which build platforms
are merely kind of unusual versus which are very unusual (obscure OS *
obscure ISA).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

On Fri, Sep 17, 2021 at 11:17:01AM +0200, Cornelia Huck wrote:
> On Fri, Sep 17 2021, David Gibson <david@gibson.dropbear.id.au> 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
> 
> Thank you for doing that!
> 
> >
> > 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.
> 
> Yes :(
> 
> Do we actually have an idea what we would require?

Not t this stage.  This is just based on the ticks in the table on the
Rust page, I haven't tried to look closer at any of the cases.

> I'm surprised that
> there are so many targets without host tools or without std support (but
> maybe they are only missing small things.)

Right.  So, it makes sense that Rust has a bunch of targets without
that support: a lot of them are embedded systems, where you'd expect
to be cross-compiling.  The intersection of that with the qemu build
platforms is weirder.

> > I've included some notes on where the information comes from, and some
> > uncertainties in there.
> >
> > I've made an effort to get the information correct, but double
> > checking would be appreciated.
> 
> I did not spot any errors on a quick cross check, but I'm not really
> sure about what the BSDs support.
> 
> >
> > I haven't yet looked into the packaging situation for the Rust
> > toolchain on various platforms and distros, but I still intend to do
> > so.
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

Le ven. 17 sept. 2021 10:58, David Gibson <david@gibson.dropbear.id.au> a
écrit :

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

Could user mode emulation be impacted by this decision? What code used by
user emulation could potentially be converted to Rust?

>

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Fri, Sep 17, 2021 at 01:11:56PM +0200, Philippe Mathieu-Daudé wrote:
> Le ven. 17 sept. 2021 10:58, David Gibson <david@gibson.dropbear.id.au> a
> écrit :
> 
> > 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
> >
> 
> Could user mode emulation be impacted by this decision? What code used by
> user emulation could potentially be converted to Rust?

qemu-user does not have the same security requirements as qemu-system,
since the application is running under a given uid/gid on the host
system and can invoke system calls.

I think the benefits of Rust in qemu-user would be more around
expressiveness (language constructs like pattern matching, traits, etc)
and correctness (memory leaks, concurrency, etc). Both benefits might
motivate someone to write parts of qemu-user in Rust, so I guess the
answer is "all of it potentially could be converted". It's impossible to
know until someone contributes patches.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Fri, Sep 17, 2021 at 04:56:02PM +0100, Stefan Hajnoczi wrote:
> On Fri, Sep 17, 2021 at 01:11:56PM +0200, Philippe Mathieu-Daudé wrote:
> > Le ven. 17 sept. 2021 10:58, David Gibson <david@gibson.dropbear.id.au> a
> > écrit :
> > 
> > > 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
> > >
> > 
> > Could user mode emulation be impacted by this decision? What code used by
> > user emulation could potentially be converted to Rust?
> 
> qemu-user does not have the same security requirements as qemu-system,
> since the application is running under a given uid/gid on the host
> system and can invoke system calls.
> 
> I think the benefits of Rust in qemu-user would be more around
> expressiveness (language constructs like pattern matching, traits, etc)
> and correctness (memory leaks, concurrency, etc). Both benefits might
> motivate someone to write parts of qemu-user in Rust, so I guess the
> answer is "all of it potentially could be converted". It's impossible to
> know until someone contributes patches.

Right.  It certainly could be used there, but I don't know it's the
most promising or interesting area for it.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Daniel P. Berrangé]

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)

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

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.

macOS on Apple silicon is a non-x86 non-Linux host platform that is
currently receiving some developer attention. Luckily
aarch64-apple-darwin is in Tier 2 with host tools.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

On Fri, Sep 17, 2021 at 04:59:09PM +0100, Stefan Hajnoczi wrote:
65;6402;1c> 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.
> 
> macOS on Apple silicon is a non-x86 non-Linux host platform that is
> currently receiving some developer attention. Luckily
> aarch64-apple-darwin is in Tier 2 with host tools.

Yeah, I was figuring macOS on aarch64 would be important with macOS
moving to ARM.  But as you say, that is ok in rust.  Not so much
"luckily" as that being a consequence of it being a fairly active
platform in general.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5362 bytes --]

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

[Philippe Mathieu-Daudé]

On 9/17/21 6:04 PM, Warner Losh wrote:> 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.

What part of QEMU is used there, user-emulation (likely IMO) or
system-emulation (unlikely) or both?

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

Thanks for gathering this useful info!

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

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

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

On Fri, Sep 17, 2021, 12:39 PM Philippe Mathieu-Daudé <f4bug@amsat.org>
wrote:

> On 9/17/21 6:04 PM, Warner Losh wrote:> 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.
>
> What part of QEMU is used there, user-emulation (likely IMO) or
> system-emulation (unlikely) or both?
>

System emulation is typical.  User emulation of x86 is the only interesting
thing, but that is less complete than other arch.

> 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.
>
> Thanks for gathering this useful info!
>

You are welcome.

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

[-- Attachment #2: Type: text/html, Size: 3937 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 5857 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ed Maste]

On Mon, 20 Sept 2021 at 01:14, David Gibson <david@gibson.dropbear.id.au> wrote:
>
> 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).

That is indeed a bit confusing. If you click on the "Support Tier"
link (in the table heading) it's documented as:

21.6. Tier 4: Unsupported Architectures
Tier 4 platforms are not supported in any form by the project.

We (FreeBSD) should really just remove that and replace Tier 4 with unsupported.

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

Yes, good idea. I've had discussions with a few Arm folks about
improving the rust tier for FreeBSD/arm64, but should do this for
x86_64 as well.

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2808 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Brad Smith]

On 9/17/2021 4:58 AM, 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.
> 
> I've included some notes on where the information comes from, and some
> uncertainties in there.
> 
> I've made an effort to get the information correct, but double
> checking would be appreciated.
> 
> I haven't yet looked into the packaging situation for the Rust
> toolchain on various platforms and distros, but I still intend to do
> so.

Regarding this entry on the Wiki page..

"I think OpenBSD lacks mips32 support, but the presence of Loongson 
means I'm having trouble pinning that down with certainty"

That is correct. Our loongson port is mips64el. OpenBSD only supports
64-bit MIPS.

OpenBSD currently only provides packages and host tools for aarch64,
amd64, i386 and sparc64.

So for the Wiki armv7, MIPS (64-bit), PPC (32-bit) should be changed
to N/A. The SPARC (64-bit) entry should be changed to yellow.

I'd like to fill in the gaps for arm, mips64, mips64el, powerpc, 
powerpc64, and riscv64.

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

On Sun, Sep 19, 2021 at 10:23:21PM -0400, Brad Smith wrote:
> On 9/17/2021 4:58 AM, 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.
> > 
> > I've included some notes on where the information comes from, and some
> > uncertainties in there.
> > 
> > I've made an effort to get the information correct, but double
> > checking would be appreciated.
> > 
> > I haven't yet looked into the packaging situation for the Rust
> > toolchain on various platforms and distros, but I still intend to do
> > so.
> 
> Regarding this entry on the Wiki page..
> 
> "I think OpenBSD lacks mips32 support, but the presence of Loongson means
> I'm having trouble pinning that down with certainty"
> 
> That is correct. Our loongson port is mips64el. OpenBSD only supports
> 64-bit MIPS.

Thanks, I've updated the page to reflect that.

> OpenBSD currently only provides packages and host tools for aarch64,
> amd64, i386 and sparc64.

Sorry, I'm not clear on what you mean by this.  Do you mean OpenBSD
provides Rust packages and tools for aarch64, amd64, i386 and sparc64?
Or some more general statement about openbsd support for those
platforms.

For purposes of this matrix, I'm considering upstream Rust support,
not toolchain packaging (I'll be looking at that later).

If you do have rust packages and host tools for sparc64, that would
imply support is better than shown on
https://doc.rust-lang.org/nightly/rustc/platform-support.html which
notes 'sparc64-unknown-openbsd' as having "unknown or WiP" std library
support and no support for building host tools.  Does that page need
to be updated?

> So for the Wiki armv7, MIPS (64-bit), PPC (32-bit) should be changed
> to N/A.

https://www.openbsd.org/plat.html lists armv7, mips64
(loongson/octeon) and ppc32 (macppc) as supported platforms.  Is that
no longer correct?

> The SPARC (64-bit) entry should be changed to yellow.

Can you confirm that your Rust port has full std library support and
can build the host tools?  If so can you talk to the Rust people about
updating their page?

> I'd like to fill in the gaps for arm, mips64, mips64el, powerpc, powerpc64,
> and riscv64.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]