* Rust in Qemu BoF followup: Rust vs. qemu platform support @ 2021-09-17 8:58 David Gibson 2021-09-17 9:17 ` Cornelia Huck ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: David Gibson @ 2021-09-17 8:58 UTC (permalink / raw) To: qemu-devel Cc: peter.maydell, slp, cohuck, f4bug, hreitz, stefanha, pbonzini, marcandre.lureau, alex.bennee, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 8:58 Rust in Qemu BoF followup: Rust vs. qemu platform support David Gibson @ 2021-09-17 9:17 ` Cornelia Huck 2021-09-17 9:54 ` Marc-André Lureau 2021-09-17 10:56 ` David Gibson 2021-09-17 11:11 ` Philippe Mathieu-Daudé ` (2 subsequent siblings) 3 siblings, 2 replies; 23+ messages in thread From: Cornelia Huck @ 2021-09-17 9:17 UTC (permalink / raw) To: David Gibson, qemu-devel Cc: peter.maydell, slp, f4bug, hreitz, stefanha, pbonzini, marcandre.lureau, alex.bennee, sgarzare 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 9:17 ` Cornelia Huck @ 2021-09-17 9:54 ` Marc-André Lureau 2021-09-17 11:03 ` David Gibson 2021-09-17 10:56 ` David Gibson 1 sibling, 1 reply; 23+ messages in thread From: Marc-André Lureau @ 2021-09-17 9:54 UTC (permalink / raw) To: Cornelia Huck Cc: Peter Maydell, Sergio Lopez, Philippe Mathieu-Daudé, QEMU, hreitz, Stefan Hajnoczi, Paolo Bonzini, Stefano Garzarella, Alex Bennée, David Gibson [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 9:54 ` Marc-André Lureau @ 2021-09-17 11:03 ` David Gibson 2021-09-18 20:01 ` Richard Henderson 0 siblings, 1 reply; 23+ messages in thread From: David Gibson @ 2021-09-17 11:03 UTC (permalink / raw) To: Marc-André Lureau Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, QEMU, Philippe Mathieu-Daudé, hreitz, Stefan Hajnoczi, Paolo Bonzini, Alex Bennée, Stefano Garzarella [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 11:03 ` David Gibson @ 2021-09-18 20:01 ` Richard Henderson 2021-09-20 3:41 ` David Gibson 0 siblings, 1 reply; 23+ messages in thread From: Richard Henderson @ 2021-09-18 20:01 UTC (permalink / raw) To: David Gibson, Marc-André Lureau Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, QEMU, Philippe Mathieu-Daudé, hreitz, Stefan Hajnoczi, Paolo Bonzini, Alex Bennée, Stefano Garzarella 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~ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-18 20:01 ` Richard Henderson @ 2021-09-20 3:41 ` David Gibson 2021-09-20 8:13 ` Peter Maydell 0 siblings, 1 reply; 23+ messages in thread From: David Gibson @ 2021-09-20 3:41 UTC (permalink / raw) To: Richard Henderson Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, QEMU, Philippe Mathieu-Daudé, hreitz, Marc-André Lureau, Stefan Hajnoczi, Paolo Bonzini, Alex Bennée, Stefano Garzarella [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-20 3:41 ` David Gibson @ 2021-09-20 8:13 ` Peter Maydell 2021-09-21 5:57 ` David Gibson 0 siblings, 1 reply; 23+ messages in thread From: Peter Maydell @ 2021-09-20 8:13 UTC (permalink / raw) To: David Gibson Cc: Sergio Lopez, Cornelia Huck, Richard Henderson, QEMU, Philippe Mathieu-Daudé, Hanna Reitz, Marc-André Lureau, Stefan Hajnoczi, Paolo Bonzini, Alex Bennée, Stefano Garzarella 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-20 8:13 ` Peter Maydell @ 2021-09-21 5:57 ` David Gibson 0 siblings, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-21 5:57 UTC (permalink / raw) To: Peter Maydell Cc: Sergio Lopez, Cornelia Huck, Richard Henderson, QEMU, Philippe Mathieu-Daudé, Hanna Reitz, Marc-André Lureau, Stefan Hajnoczi, Paolo Bonzini, Alex Bennée, Stefano Garzarella [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 9:17 ` Cornelia Huck 2021-09-17 9:54 ` Marc-André Lureau @ 2021-09-17 10:56 ` David Gibson 1 sibling, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-17 10:56 UTC (permalink / raw) To: Cornelia Huck Cc: peter.maydell, slp, qemu-devel, f4bug, hreitz, stefanha, pbonzini, marcandre.lureau, alex.bennee, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 8:58 Rust in Qemu BoF followup: Rust vs. qemu platform support David Gibson 2021-09-17 9:17 ` Cornelia Huck @ 2021-09-17 11:11 ` Philippe Mathieu-Daudé 2021-09-17 15:56 ` Stefan Hajnoczi 2021-09-17 11:34 ` Daniel P. Berrangé 2021-09-20 2:23 ` Brad Smith 3 siblings, 1 reply; 23+ messages in thread From: Philippe Mathieu-Daudé @ 2021-09-17 11:11 UTC (permalink / raw) To: David Gibson Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, qemu-devel@nongnu.org Developers, hreitz, Stefan Hajnoczi, Paolo Bonzini, Marc-André Lureau, Alex Bennée, Stefano Garzarella [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 11:11 ` Philippe Mathieu-Daudé @ 2021-09-17 15:56 ` Stefan Hajnoczi 2021-09-18 5:25 ` David Gibson 0 siblings, 1 reply; 23+ messages in thread From: Stefan Hajnoczi @ 2021-09-17 15:56 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, qemu-devel@nongnu.org Developers, hreitz, Marc-André Lureau, Paolo Bonzini, Stefano Garzarella, Alex Bennée, David Gibson [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 15:56 ` Stefan Hajnoczi @ 2021-09-18 5:25 ` David Gibson 0 siblings, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-18 5:25 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Peter Maydell, Sergio Lopez, Cornelia Huck, Philippe Mathieu-Daudé, qemu-devel@nongnu.org Developers, hreitz, Marc-André Lureau, Paolo Bonzini, Alex Bennée, Stefano Garzarella [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 8:58 Rust in Qemu BoF followup: Rust vs. qemu platform support David Gibson 2021-09-17 9:17 ` Cornelia Huck 2021-09-17 11:11 ` Philippe Mathieu-Daudé @ 2021-09-17 11:34 ` Daniel P. Berrangé 2021-09-17 15:59 ` Stefan Hajnoczi ` (2 more replies) 2021-09-20 2:23 ` Brad Smith 3 siblings, 3 replies; 23+ messages in thread From: Daniel P. Berrangé @ 2021-09-17 11:34 UTC (permalink / raw) To: David Gibson Cc: peter.maydell, slp, cohuck, qemu-devel, f4bug, hreitz, stefanha, marcandre.lureau, pbonzini, alex.bennee, sgarzare 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 :| ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 11:34 ` Daniel P. Berrangé @ 2021-09-17 15:59 ` Stefan Hajnoczi 2021-09-18 5:28 ` David Gibson 2021-09-17 16:04 ` Warner Losh 2021-09-20 3:43 ` David Gibson 2 siblings, 1 reply; 23+ messages in thread From: Stefan Hajnoczi @ 2021-09-17 15:59 UTC (permalink / raw) To: Daniel P. Berrangé Cc: peter.maydell, slp, cohuck, f4bug, qemu-devel, hreitz, marcandre.lureau, pbonzini, sgarzare, alex.bennee, David Gibson [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 15:59 ` Stefan Hajnoczi @ 2021-09-18 5:28 ` David Gibson 0 siblings, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-18 5:28 UTC (permalink / raw) To: Stefan Hajnoczi Cc: peter.maydell, Daniel P. Berrangé, slp, cohuck, qemu-devel, f4bug, hreitz, marcandre.lureau, pbonzini, alex.bennee, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 11:34 ` Daniel P. Berrangé 2021-09-17 15:59 ` Stefan Hajnoczi @ 2021-09-17 16:04 ` Warner Losh 2021-09-17 18:39 ` Philippe Mathieu-Daudé 2021-09-20 3:53 ` David Gibson 2021-09-20 3:43 ` David Gibson 2 siblings, 2 replies; 23+ messages in thread From: Warner Losh @ 2021-09-17 16:04 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Peter Maydell, slp, cohuck, Philippe Mathieu-Daudé, QEMU Developers, Max Reitz, Stefan Hajnoczi, Paolo Bonzini, Marc-André Lureau, sgarzare, Alex Bennée, David Gibson [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 16:04 ` Warner Losh @ 2021-09-17 18:39 ` Philippe Mathieu-Daudé 2021-09-17 19:02 ` Warner Losh 2021-09-20 3:53 ` David Gibson 1 sibling, 1 reply; 23+ messages in thread From: Philippe Mathieu-Daudé @ 2021-09-17 18:39 UTC (permalink / raw) To: Warner Losh, Daniel P. Berrangé Cc: Peter Maydell, slp, cohuck, QEMU Developers, Max Reitz, Stefan Hajnoczi, Marc-André Lureau, Paolo Bonzini, David Gibson, Alex Bennée, sgarzare 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... > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 18:39 ` Philippe Mathieu-Daudé @ 2021-09-17 19:02 ` Warner Losh 0 siblings, 0 replies; 23+ messages in thread From: Warner Losh @ 2021-09-17 19:02 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Peter Maydell, Daniel P. Berrangé, slp, cohuck, QEMU Developers, Max Reitz, Stefan Hajnoczi, Marc-André Lureau, Paolo Bonzini, David Gibson, Alex Bennée, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 16:04 ` Warner Losh 2021-09-17 18:39 ` Philippe Mathieu-Daudé @ 2021-09-20 3:53 ` David Gibson 2021-09-20 13:58 ` Ed Maste 1 sibling, 1 reply; 23+ messages in thread From: David Gibson @ 2021-09-20 3:53 UTC (permalink / raw) To: Warner Losh Cc: Peter Maydell, Daniel P. Berrangé, slp, cohuck, QEMU Developers, Philippe Mathieu-Daudé, Max Reitz, Stefan Hajnoczi, Paolo Bonzini, Marc-André Lureau, Alex Bennée, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-20 3:53 ` David Gibson @ 2021-09-20 13:58 ` Ed Maste 0 siblings, 0 replies; 23+ messages in thread From: Ed Maste @ 2021-09-20 13:58 UTC (permalink / raw) To: David Gibson; +Cc: QEMU Developers, Warner Losh 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 11:34 ` Daniel P. Berrangé 2021-09-17 15:59 ` Stefan Hajnoczi 2021-09-17 16:04 ` Warner Losh @ 2021-09-20 3:43 ` David Gibson 2 siblings, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-20 3:43 UTC (permalink / raw) To: Daniel P. Berrangé Cc: peter.maydell, slp, cohuck, qemu-devel, f4bug, hreitz, stefanha, marcandre.lureau, pbonzini, alex.bennee, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-17 8:58 Rust in Qemu BoF followup: Rust vs. qemu platform support David Gibson ` (2 preceding siblings ...) 2021-09-17 11:34 ` Daniel P. Berrangé @ 2021-09-20 2:23 ` Brad Smith 2021-09-20 4:07 ` David Gibson 3 siblings, 1 reply; 23+ messages in thread From: Brad Smith @ 2021-09-20 2:23 UTC (permalink / raw) To: David Gibson, qemu-devel Cc: peter.maydell, slp, cohuck, f4bug, hreitz, stefanha, pbonzini, marcandre.lureau, alex.bennee, sgarzare 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Rust in Qemu BoF followup: Rust vs. qemu platform support 2021-09-20 2:23 ` Brad Smith @ 2021-09-20 4:07 ` David Gibson 0 siblings, 0 replies; 23+ messages in thread From: David Gibson @ 2021-09-20 4:07 UTC (permalink / raw) To: Brad Smith Cc: peter.maydell, slp, cohuck, qemu-devel, f4bug, hreitz, stefanha, marcandre.lureau, pbonzini, alex.bennee, sgarzare [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2021-09-21 6:39 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-17 8:58 Rust in Qemu BoF followup: Rust vs. qemu platform support David Gibson 2021-09-17 9:17 ` Cornelia Huck 2021-09-17 9:54 ` Marc-André Lureau 2021-09-17 11:03 ` David Gibson 2021-09-18 20:01 ` Richard Henderson 2021-09-20 3:41 ` David Gibson 2021-09-20 8:13 ` Peter Maydell 2021-09-21 5:57 ` David Gibson 2021-09-17 10:56 ` David Gibson 2021-09-17 11:11 ` Philippe Mathieu-Daudé 2021-09-17 15:56 ` Stefan Hajnoczi 2021-09-18 5:25 ` David Gibson 2021-09-17 11:34 ` Daniel P. Berrangé 2021-09-17 15:59 ` Stefan Hajnoczi 2021-09-18 5:28 ` David Gibson 2021-09-17 16:04 ` Warner Losh 2021-09-17 18:39 ` Philippe Mathieu-Daudé 2021-09-17 19:02 ` Warner Losh 2021-09-20 3:53 ` David Gibson 2021-09-20 13:58 ` Ed Maste 2021-09-20 3:43 ` David Gibson 2021-09-20 2:23 ` Brad Smith 2021-09-20 4:07 ` David Gibson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.