Rust BoF and maintainer minutes and planning the roadmap to Rust

Rust BoF and maintainer minutes and planning the roadmap to Rust

[Alex Bennée]

Hi,

We discussed the topic of Rust for QEMU at KVM Forum over the weekend.
Aside from its mention in the QEMU Status update we also held a BoF on
Sunday evening and had a smaller discussion amongst some of the
maintainers on Monday lunchtime. I'm going to try and summarise points
from all of those here. As these groups were self selecting the
intention is for this thread to gather feedback from developers and
packagers who weren't present as well as a chance for others to add to
anything I've missed from my notes.

Road map and statement of intention
-----------------------------------

One of the points that came up in reference to other projects is that
making our intentions clear was important. Are we treating the
introduction of Rust as an experiment to be analysed further down the
road or the start of a "planned" migration to the language?

As QEMU is widely packaged it will be important to have a clear road map
so distros can plan for Rust's inclusion. We also want them to feedback
on technical choices before they are baked in to make the process as
smooth as possible.

The topic of moving the implementation of QEMU to another language has
been discussed amongst developers for a long time. Previous discussions
about migrating to C++ never got very far and the general feeling was
that any migration should be to something that offers tangible benefits
other than being a "slightly better C".

While Go has also been touted as a potential language it seems Rust has
the growing mind share and over the years is seeing growing production
usage. There are already a number of QEMU-adjacent projects such as
virtiofs and rust-vmm which are delivering production grade binaries
that indicate it is a good fit for QEMU itself.

During the various conversations I didn't hear anyone speak against the
proposed migration although some concerns where raised about review and
knowledge gaps.

One output from this discussion should be a clear statement that we are
going forward with this work and the road map. A rough roadmap might
look like:

  - 9.2   --enable-rust is available and developers can build with it.
          rust devices have -x-device or -rust-device CLI flags for
          runtime selection.

  - 10.x  rust devices feature complete and migration compatible, enabled
          by default when rust compiler detected. No CLI selection
          required as legacy portions won't be built. Any partial
          conversions should be behind --enable-prototype-rust configure
          flag.

  - 11.x  distros have enough infrastructure to build on supported
          platforms. Rust becomes a mandatory dependency, old C versions
          of converted code removed from build.

  - xx.y  QEMU becomes a pure native rust program and all C is expunged.
          We may never get to this point.

We should publish the intention and the road map prominently although it
was unclear if a blog post would be the best place vs expanding a
section in the developers manual. Perhaps both make sense with a blog
post for the statement of intent and rough timeline and the developer
manual being expanded with any new rules and standards to follow?

There was some concern about the missing gaps in the support matrix
especially as we support a number of "legacy" TCG backends. While *-user
support is more insulated from the effects of rust conversions due to
its relatively low set of dependencies it will still be a problem if we
convert the core CPU QOM classes to rust.

Some of this is made simpler if we deprecate 32 bit host support?

In theory if LLVM supports the architecture we should be able to
generate binaries with a rust compiler although we may not have all
tools available on that host.

What are candidates for conversion?
-----------------------------------

One area of discussion was what areas of the code base are likely to be
converted. This will give maintainers some idea of what to expect over
the next few cycles as we move ahead.

Manos' initial patch series [1] adds a pl011 serial device and there is
an intention to add a pflash device model to exercise the block layer.
It was suggested other device models such as a network card and watchdog
device would also be worth doing a conversion for to exercise other
common backends.

While device models are a good candidate for early conversion as they
interact with un-trusted guest data there are other areas that might
also benefit from conversion.

Hanna and Stefan were keen to see more use of Rust in the block layer.
Hanna cautioned that it was hard to find a reasonable starting point for
the conversion. Originally she had started with the core sub-system but
it quickly ran into thousands of lines of code which would be hard to
get well reviewed before switching for such a crucial sub-system. Maybe
this is an ordering problem and it would make more sense to start with
individual block drivers first and work up from there.

Alex mentioned softfloat could make a good candidate for conversion as
while the rewrite had made things easier to follow and extend there were
still some C macro tricks employed to get code re-use. It would depend
on if Rust's macro and trait system allows more of the common logic to
be kept together.

The qboot firmware for MicroVM's was also mentioned as a potential
candidate.

Markus asked when will QAPI need rust bindings? As it is the route for
the public API into QEMU it is spread widely across the code base. While
the hand written serialisation code can likely be replaced with Rust's
serde crate it will need to interface to the internal APIs of both rust
and C modules.

Another potential area for conversion was the VirtIO device and
vhost-user code which could expect to re-use a lot of the crates from
the rust-vmm project. However this did bring up the point of maintainer
buy in. Stefan brought up the example of the simpletrace rewrite which
while it may have brought some advantages he felt he was unable to take
as a maintainer as he was not familiar with Rust at that point.

Developer Expertise and Language policies
-----------------------------------------

One issue that came up is how we handle adequately reviewing code when
most of the maintainers are experienced C coders but might not know much
about Rust. While we want to avoid the situation of developers vetoing
conversion there should be communication ahead of any serious work to
avoid rust contributions coming out of the blue. If a maintainer feels
they cannot maintain a bunch of unfamiliar rust code the submitter
should be prepared to find people willing to become a maintainers as
unmaintained drive-by submissions are not useful for the long term
health of the project.

With relative inexperience there was a concern we could inadvertently
introduce technical debt in the code base (C-like Rust vs Rusty rust).
What can we do to mitigate that issue?

Of the ~16 people at the Rust BoF about 11 had written production rust
code and a further 3 where rust curious. Those that attended the BoF
where likely the majority of Rust experts in the community. This implies
what reviewers we have in the community will be thinly spread out.

We make heavy use of GLib throughout the code base and while new Rust
code should use native structures for arrays and the like there are
places when Glib structures are passed across API boundaries. Should we
consider updating APIs as we go or live with a degree of thunking until
we have a better idea where the pain points are?

How will this affect QEMU's declared security boundaries? Do we need to
develop a policy on the use of unsafe{} sections in the code and how we
interact with the wider C code?

One of the promises of Rust is its support for inline unit test
integration although there was a little confusion about how this works
in practice. Are separate test binaries created with just the code under
test or is there a unit testable build of QEMU itself? Does this still
work with mixed C and Rust code?

It was suggested creating a qemu-rust mailing list that all patches that
touch or introduce rust could Cc. This would help those willing to
review rust find patches without having to wade through the qemu-devel
firehose.

Dependencies and Packaging concerns
-----------------------------------

Finally there is the topic of dependencies and how that affects
packaging. One of the benefits of Rust is a large library of crates for
common dependencies. Typically the management of those crates is handled
by the cargo build tool and projects tend to regularly update their
dependencies to stay current with the state of the art. However this
cargo driven approach is at odds with a lot of distros desire to package
a single version of a library and manage its updates during the stable
lifetime of a distro. Some distros do allow exceptions for "vendoring"
dependencies as part of the build but it is generally discouraged.

Another challenge is updating versions of crates can often lead to
additional transitive (indirect) dependencies which then need to be
checked if they are supported by our distro matrix.

The s390-tools maintainer spoke about their experience and how important
it was to engage proactively with distro maintainers (part of the reason
a chunk are Cc'd in this email). When there was common source shared
amongst the tools they published to crates.io to make it easier for
distros to ingest the packages.

The general consensus seemed to be we should be fairly conservative
about adding new crate dependencies while the Rust ecosystem in distros
matures. While we should support rustup/cargo installed tools so
developers can build and test on existing LTS distros we should be
aiming to build QEMU without downloading any additional packages. There
may be some flexibility for build-only dependencies (c.f. our pyenv) but
runtime dependencies should be served by the distro itself.

Final notes
-----------

From my point of view the contributors to all these sessions seemed
pretty positive about the benefits of bringing Rust into the project
while expressing some concerns about managing community expertise during
the migration. While a self selecting group there were no indications we
should be investigating other languages and a general feeling Rust
fitted well with the sorts of tasks QEMU has to manage.

As such I welcome all constructive feedback on this thread as we consult
with community and the many downstream consumers of the QEMU project. By
developing a clear plan of action I hope we can make the proposed
migration a successful one that will benefit the project in the years to
come.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

[1] https://patchew.org/QEMU/20240910-rust-pl011-v10-0-85a89ee33c40@linaro.org/

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Stefan Hajnoczi]

On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@linaro.org> wrote:
> What are candidates for conversion?

"Conversion" means "rewrite in Rust" to me. There are other ways of
integrating Rust without converting existing code:

- Writing new subsystems in Rust where there is no existing C code.
- Adding Rust bindings to existing subsystems so that new code (e.g.
device models) can optionally be written in Rust while still allowing
new C code.

Let's speak more broadly about "integrating Rust" rather than
"conversion", which is just one of the ways to use Rust in QEMU.

> Hanna and Stefan were keen to see more use of Rust in the block layer.
> Hanna cautioned that it was hard to find a reasonable starting point for
> the conversion. Originally she had started with the core sub-system but
> it quickly ran into thousands of lines of code which would be hard to
> get well reviewed before switching for such a crucial sub-system. Maybe
> this is an ordering problem and it would make more sense to start with
> individual block drivers first and work up from there.

Hanna's Rust Storage Daemon (basically a Rust version of the QEMU
block layer as an external process) is here:
https://gitlab.com/hreitz/rsd

> Another potential area for conversion was the VirtIO device and
> vhost-user code which could expect to re-use a lot of the crates from
> the rust-vmm project. However this did bring up the point of maintainer
> buy in. Stefan brought up the example of the simpletrace rewrite which
> while it may have brought some advantages he felt he was unable to take
> as a maintainer as he was not familiar with Rust at that point.

Familiarity with Rust was not the issue with simpletrace. I had
already worked on libblkio in Rust and was able to understand the Rust
simpletrace patches.

It was a question of when rewriting in Rust is appropriate. Surprising
maintainers with a rewrite is risky because they may not be convinced
by the rewrite after all the work to write it has been done.

In the case of simpletrace there wasn't a clear benefit to a rewrite:
performance was potentially better in Rust (performance hadn't been a
problem for users though) but usability was impacted by converting a
scriptable Python module to Rust (requiring users to rewrite their
scripts). The rewrite was dropped.

What I tried to express at the Rust BoF was: talk to maintainers
before embarking on a rewrite.

> With relative inexperience there was a concern we could inadvertently
> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> What can we do to mitigate that issue?

My suggestion is that every `unsafe` needs a comment explaining why it
is safe. That increases the cost of using `unsafe` and encourages safe
abstractions.

There are plenty of unidiomatic ways of using Rust, but none are as
bad as sprinkling `unsafe` everywhere (i.e. writing C in Rust) since
that's how undefined behavior is introduced.

Stefan

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Daniel P. Berrangé]

On Thu, Sep 26, 2024 at 03:23:11PM +0100, Alex Bennée wrote:
> During the various conversations I didn't hear anyone speak against the
> proposed migration although some concerns where raised about review and
> knowledge gaps.

Yep, this apparent broad acceptance (or at least tolerance) for use of
Rust is a clear difference from any previous discussion about introducing
new languages in QEMU n the past.

> 
> One output from this discussion should be a clear statement that we are
> going forward with this work and the road map. A rough roadmap might
> look like:
> 
>   - 9.2   --enable-rust is available and developers can build with it.
>           rust devices have -x-device or -rust-device CLI flags for
>           runtime selection.
> 
>   - 10.x  rust devices feature complete and migration compatible, enabled
>           by default when rust compiler detected. No CLI selection
>           required as legacy portions won't be built. Any partial
>           conversions should be behind --enable-prototype-rust configure
>           flag.
> 
>   - 11.x  distros have enough infrastructure to build on supported
>           platforms. Rust becomes a mandatory dependency, old C versions
>           of converted code removed from build.
> 
>   - xx.y  QEMU becomes a pure native rust program and all C is expunged.
>           We may never get to this point.

Yeah, I think this last step is soo unlikely (or far away) that we could
reasonably just not include it at all. Perhaps any future grandchildren
will do this part for us ;-P

> We should publish the intention and the road map prominently although it
> was unclear if a blog post would be the best place vs expanding a
> section in the developers manual. Perhaps both make sense with a blog
> post for the statement of intent and rough timeline and the developer
> manual being expanded with any new rules and standards to follow?

We should include plans about Rust at the top of the release notes too
for all forthcoming versions until we have it turned on permanently.

> There was some concern about the missing gaps in the support matrix
> especially as we support a number of "legacy" TCG backends. While *-user
> support is more insulated from the effects of rust conversions due to
> its relatively low set of dependencies it will still be a problem if we
> convert the core CPU QOM classes to rust.
> 
> Some of this is made simpler if we deprecate 32 bit host support?

I feel like we're pretty close to wanting todo this regardless of
Rust support.

> What are candidates for conversion?
> -----------------------------------
> 
> One area of discussion was what areas of the code base are likely to be
> converted. This will give maintainers some idea of what to expect over
> the next few cycles as we move ahead.

There's a topical blog from Google about their experiance with
Android that just hit LWN:

  https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

"vulnerabilities decay exponentially. They have a half-life.
 ...
 the density of Android’s memory safety bugs decreased with
 the age of the code, primarily residing in recent changes.

  This leads to two important takeaways:

   * The problem is overwhelmingly with new code, necessitating a
     fundamental change in how we develop code.
  
   * Code matures and gets safer with time, exponentially, making
     the returns on investments like rewrites diminish over time
     as code gets older."

IOW, if we rush into conversion of existing code, we're likely to
harm QEMU's quality in the short-medium term.

We should thus encourage/prioritize use of Rust for *new* code, and
be more cautious / targetted about converting existing code, to
mitigate the risks inherant in any rewrites.

> Manos' initial patch series [1] adds a pl011 serial device and there is
> an intention to add a pflash device model to exercise the block layer.
> It was suggested other device models such as a network card and watchdog
> device would also be worth doing a conversion for to exercise other
> common backends.

If we want arbitrary new devices to be able to be written in Rust,
we want to make sure we have the backends accessible to the Rust
frontend device, for developers to consume.

To be able to design & validate any Rust abstractions for backends,
we need to have at least 1 Rust device consuming each different
backend type eg, chardev, netdev, blockdev, tpm, rng, watchdog.
Similarly for other helper code like IO channels, crypto.

> Markus asked when will QAPI need rust bindings? As it is the route for
> the public API into QEMU it is spread widely across the code base. While
> the hand written serialisation code can likely be replaced with Rust's
> serde crate it will need to interface to the internal APIs of both rust
> and C modules.

Probably need some kind of QAPI support sooner than we think, given how
widely it spreads.

> One issue that came up is how we handle adequately reviewing code when
> most of the maintainers are experienced C coders but might not know much
> about Rust. While we want to avoid the situation of developers vetoing
> conversion there should be communication ahead of any serious work to
> avoid rust contributions coming out of the blue. If a maintainer feels
> they cannot maintain a bunch of unfamiliar rust code the submitter
> should be prepared to find people willing to become a maintainers as
> unmaintained drive-by submissions are not useful for the long term
> health of the project.

Yep, communication is critical, if proposing to rewrite existing
functionality. Drowning maintainers in conversion patches without
warning is a guaranteed way to create friction between people.

> With relative inexperience there was a concern we could inadvertently
> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> What can we do to mitigate that issue?

On a long enough time frame, all exiting code can be considered
technical debt. Given the relatively sparse Rust experiance
across our community, we're guaranteed to make more design
mistakes in the first few years. Mitigating this is important,
but at the same time, we should also accept we're not going
to get everything perfect.

One thing our community is very good at is obsessing about
perfection of patch series. I can forsee us doing that to an
even greater extent with any Rust conversions of code. If we
are not careful we could really harm  our overall productivity
by spending too much time striving for a perfect Rust abstraction
first time out, even though many of us would still be relative
newcomers to Rust, such that we don't know what we don't know.

IOW, we need to be pragmatic about accepting some level of
technical debt at times. Especially if there are cases where
our Rust design is held back by existing C code, we might be
better off temporarily accepting sub-optimal Rust, to avoid
immediately refactoring piles of C code, and tackle the problems
later.

> Dependencies and Packaging concerns
> -----------------------------------
> 
> Finally there is the topic of dependencies and how that affects
> packaging. One of the benefits of Rust is a large library of crates for
> common dependencies. Typically the management of those crates is handled
> by the cargo build tool and projects tend to regularly update their
> dependencies to stay current with the state of the art. However this
> cargo driven approach is at odds with a lot of distros desire to package
> a single version of a library and manage its updates during the stable
> lifetime of a distro. Some distros do allow exceptions for "vendoring"
> dependencies as part of the build but it is generally discouraged.


> Another challenge is updating versions of crates can often lead to
> additional transitive (indirect) dependencies which then need to be
> checked if they are supported by our distro matrix.

In terms of our distro support matrix, I think we should follow the
same practice as Python. ie we only check that the distro provides
the required toolchain / base language, and never check the crates.
IMHO vendoring is really the only viable option for distros with
non-trivial applications, as IME the de-vendoring crates waaaaay
too much busy-work in the distro.


With 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 BoF and maintainer minutes and planning the roadmap to Rust

[Junjie Mao]

Alex Bennée <alex.bennee@linaro.org> writes:

[snip]

>
> Another potential area for conversion was the VirtIO device and
> vhost-user code which could expect to re-use a lot of the crates from
> the rust-vmm project. However this did bring up the point of maintainer
> buy in. Stefan brought up the example of the simpletrace rewrite which
> while it may have brought some advantages he felt he was unable to take
> as a maintainer as he was not familiar with Rust at that point.

I'm especially interested in how QEMU can leverage the rust-vmm project,
though to what extent that is beneficial for QEMU is yet to be discussed:

a. An increasing number of virtio device types are being developed in
the vhost-device crate which is expected to be reused by monolithic
VMMs. However, QEMU can already talk to those backends via the
vhost-user protocol. I'm not sure if it is necessary to go one step
further by integrating those backends into the QEMU binary. One benefit
in my mind is to keep VGA compatibility (which virito-gpu via vhost-user
does not provide), but that may not seem to be that significant.

b. Concerning the virtio basic facilities (virtqueues, config space,
etc.) and the vhost-user protocol, QEMU already has an implementation
that has been tested for years. As Daneil has pointed out, replacing
them with rust-vmm components puts risks QEMU's short/mid-term quality.

Comments on this from the community, esp. the maintainers, are extremely
valuable and highly appreciated.

>
> Developer Expertise and Language policies
> -----------------------------------------
>
[snip]
>
> How will this affect QEMU's declared security boundaries? Do we need to
> develop a policy on the use of unsafe{} sections in the code and how we
> interact with the wider C code?

+1 for a policy on unsafe code in Rust because inapproriate use of
unsafe code can put Rust's safety guarantees in vain.

Especially for unsafe functions or traits, their extra safety conditions
shall be stated in the code so that their users are aware of them and
can check if such conditions are met in their context. That also makes
any change to those safety conditions explicit.

>
> One of the promises of Rust is its support for inline unit test
> integration although there was a little confusion about how this works
> in practice. Are separate test binaries created with just the code under
> test or is there a unit testable build of QEMU itself? Does this still
> work with mixed C and Rust code?

My experience with Rust unit testing is that cargo generate a separate
executable that links the crate under test, dependencies of that crate
and a test driver. In that sense, I don't think mixed C/Rust code can be
unit-tested in the current draft of Rust enabling where the C and Rust
code are separately built into libraries and finally linked together.

--
Best Regards
Junjie Mao

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Sep 26, 2024 at 03:23:11PM +0100, Alex Bennée wrote:

[...]

>> One issue that came up is how we handle adequately reviewing code when
>> most of the maintainers are experienced C coders but might not know much
>> about Rust. While we want to avoid the situation of developers vetoing
>> conversion there should be communication ahead of any serious work to
>> avoid rust contributions coming out of the blue. If a maintainer feels
>> they cannot maintain a bunch of unfamiliar rust code the submitter
>> should be prepared to find people willing to become a maintainers as
>> unmaintained drive-by submissions are not useful for the long term
>> health of the project.
>
> Yep, communication is critical, if proposing to rewrite existing
> functionality. Drowning maintainers in conversion patches without
> warning is a guaranteed way to create friction between people.
>
>> With relative inexperience there was a concern we could inadvertently
>> introduce technical debt in the code base (C-like Rust vs Rusty rust).
>> What can we do to mitigate that issue?
>
> On a long enough time frame, all exiting code can be considered
> technical debt. Given the relatively sparse Rust experiance
> across our community, we're guaranteed to make more design
> mistakes in the first few years. Mitigating this is important,
> but at the same time, we should also accept we're not going
> to get everything perfect.
>
> One thing our community is very good at is obsessing about
> perfection of patch series. I can forsee us doing that to an
> even greater extent with any Rust conversions of code. If we
> are not careful we could really harm  our overall productivity
> by spending too much time striving for a perfect Rust abstraction
> first time out, even though many of us would still be relative
> newcomers to Rust, such that we don't know what we don't know.
>
> IOW, we need to be pragmatic about accepting some level of
> technical debt at times. Especially if there are cases where
> our Rust design is held back by existing C code, we might be
> better off temporarily accepting sub-optimal Rust, to avoid
> immediately refactoring piles of C code, and tackle the problems
> later.

A deliberate approach to explore some before we go all in could mitigate
the risk of taking on too much technical debt.

We obviously need to write instances of each interesting class of things
to ferret out the problems, and design good interfaces.  I'd recommend
to write few instances, ideally one, then let them mature some before we
create many more of them.  Prioritize gaining experience over quantity.

[...]

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Alex Bennée]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@linaro.org> wrote:
<snip>
>> Another potential area for conversion was the VirtIO device and
>> vhost-user code which could expect to re-use a lot of the crates from
>> the rust-vmm project. However this did bring up the point of maintainer
>> buy in. Stefan brought up the example of the simpletrace rewrite which
>> while it may have brought some advantages he felt he was unable to take
>> as a maintainer as he was not familiar with Rust at that point.
>
> Familiarity with Rust was not the issue with simpletrace. I had
> already worked on libblkio in Rust and was able to understand the Rust
> simpletrace patches.

Apologies for misrepresenting the issue there. My notes obviously didn't
capture that nuance. 

> It was a question of when rewriting in Rust is appropriate. Surprising
> maintainers with a rewrite is risky because they may not be convinced
> by the rewrite after all the work to write it has been done.
>
> In the case of simpletrace there wasn't a clear benefit to a rewrite:
> performance was potentially better in Rust (performance hadn't been a
> problem for users though) but usability was impacted by converting a
> scriptable Python module to Rust (requiring users to rewrite their
> scripts). The rewrite was dropped.
>
> What I tried to express at the Rust BoF was: talk to maintainers
> before embarking on a rewrite.

Yes this is the I think the key takeaway because the project would not
be able to absorb a bunch of drive-by rust rewrites from well meaning
contributors.

>> With relative inexperience there was a concern we could inadvertently
>> introduce technical debt in the code base (C-like Rust vs Rusty rust).
>> What can we do to mitigate that issue?
>
> My suggestion is that every `unsafe` needs a comment explaining why it
> is safe. That increases the cost of using `unsafe` and encourages safe
> abstractions.
>
> There are plenty of unidiomatic ways of using Rust, but none are as
> bad as sprinkling `unsafe` everywhere (i.e. writing C in Rust) since
> that's how undefined behavior is introduced.
>
> Stefan

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Stefan Hajnoczi]

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

On Mon, Sep 30, 2024, 06:24 Alex Bennée <alex.bennee@linaro.org> wrote:

> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@linaro.org>
> wrote:
> <snip>
> >> Another potential area for conversion was the VirtIO device and
> >> vhost-user code which could expect to re-use a lot of the crates from
> >> the rust-vmm project. However this did bring up the point of maintainer
> >> buy in. Stefan brought up the example of the simpletrace rewrite which
> >> while it may have brought some advantages he felt he was unable to take
> >> as a maintainer as he was not familiar with Rust at that point.
> >
> > Familiarity with Rust was not the issue with simpletrace. I had
> > already worked on libblkio in Rust and was able to understand the Rust
> > simpletrace patches.
>
> Apologies for misrepresenting the issue there. My notes obviously didn't
> capture that nuance.


No worries. Thanks for taking notes!

Stefan


>
> > It was a question of when rewriting in Rust is appropriate. Surprising
> > maintainers with a rewrite is risky because they may not be convinced
> > by the rewrite after all the work to write it has been done.
> >
> > In the case of simpletrace there wasn't a clear benefit to a rewrite:
> > performance was potentially better in Rust (performance hadn't been a
> > problem for users though) but usability was impacted by converting a
> > scriptable Python module to Rust (requiring users to rewrite their
> > scripts). The rewrite was dropped.
> >
> > What I tried to express at the Rust BoF was: talk to maintainers
> > before embarking on a rewrite.
>
> Yes this is the I think the key takeaway because the project would not
> be able to absorb a bunch of drive-by rust rewrites from well meaning
> contributors.
>
> >> With relative inexperience there was a concern we could inadvertently
> >> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> >> What can we do to mitigate that issue?
> >
> > My suggestion is that every `unsafe` needs a comment explaining why it
> > is safe. That increases the cost of using `unsafe` and encourages safe
> > abstractions.
> >
> > There are plenty of unidiomatic ways of using Rust, but none are as
> > bad as sprinkling `unsafe` everywhere (i.e. writing C in Rust) since
> > that's how undefined behavior is introduced.
> >
> > Stefan
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>

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

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Warner Losh]

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

On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> One output from this discussion should be a clear statement that we are
> going forward with this work and the road map. A rough roadmap might
> look like:
>
>   - 9.2   --enable-rust is available and developers can build with it.
>           rust devices have -x-device or -rust-device CLI flags for
>           runtime selection.
>
>   - 10.x  rust devices feature complete and migration compatible, enabled
>           by default when rust compiler detected. No CLI selection
>           required as legacy portions won't be built. Any partial
>           conversions should be behind --enable-prototype-rust configure
>           flag.
>
>   - 11.x  distros have enough infrastructure to build on supported
>           platforms. Rust becomes a mandatory dependency, old C versions
>           of converted code removed from build.
>
>   - xx.y  QEMU becomes a pure native rust program and all C is expunged.
>           We may never get to this point.
>
> We should publish the intention and the road map prominently although it
> was unclear if a blog post would be the best place vs expanding a
> section in the developers manual. Perhaps both make sense with a blog
> post for the statement of intent and rough timeline and the developer
> manual being expanded with any new rules and standards to follow?
>

FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
(which
admittedly is going away) and Tier 3 for everything else.

There was some concern about the missing gaps in the support matrix
> especially as we support a number of "legacy" TCG backends. While *-user
> support is more insulated from the effects of rust conversions due to
> its relatively low set of dependencies it will still be a problem if we
> convert the core CPU QOM classes to rust.
>

Indeed. I have great concerns here, though we've already dropped
32-bit host support for bsd-user. The status of aarch64 support and rumored
difficulty getting that rust support upgraded give me pause for concern
because it's a FreeBSD Tier 1 platform. While it basically works, the lack
of
commitment by the Rust community is troubling. Even more troubling because
rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
being available for years at this point (though maybe this info has changed
in the last month or two, the years long delay in moving off the interfaces
that the FreeBSD project obsoleted about 8 years ago is troubling on its
own).
Much of the resistance I'm told (I'm not a big rust person, so I have to
reply
on others) has been in the rust team because they don't have enough
familiarity
with FreeBSD to make any kind of decision so even properly solved issues
linger in the official upstream. The FreeBSD project critically depends on
bsd-user for its release process, though that dependency so far has been
only on x86 and aarch64, both of which work almost all the time, even if
they aren't Tier 1 rust platforms.

For -system use, this could limit where qemu runs, though to be honest
the only platform I know has users that might be affected running -system
might be RISCV.

There's similar issues with other BSDs, but I've heard even less reliable
information
about them, so I'll just leave it at that.

So a strawman timeline of 2 years strikes me as unrealistically agressive
for it to be an absolute requirement given the slow rate of change I've seen
with upstream rust WRT FreeBSD. At the very least, it would put qemu on
non-x86/non-aarch64 platforms at risk. While not a huge audience, there are
some users there. The Tier 2 status for Rust at best for FreeBSD is also a
bit worrying for elimination of all C or a big reliance on rust in the core
that
can't realistically be avoided. I'm not sure this should gate the start of
the rust
experiment, but I raise it now so as that experiment progresses towards
production
people think to talk to me or others in the FreeBSD community as they
progress.

Warner

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

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Warner Losh]

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

On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
>
>> One output from this discussion should be a clear statement that we are
>> going forward with this work and the road map. A rough roadmap might
>> look like:
>>
>>   - 9.2   --enable-rust is available and developers can build with it.
>>           rust devices have -x-device or -rust-device CLI flags for
>>           runtime selection.
>>
>>   - 10.x  rust devices feature complete and migration compatible, enabled
>>           by default when rust compiler detected. No CLI selection
>>           required as legacy portions won't be built. Any partial
>>           conversions should be behind --enable-prototype-rust configure
>>           flag.
>>
>>   - 11.x  distros have enough infrastructure to build on supported
>>           platforms. Rust becomes a mandatory dependency, old C versions
>>           of converted code removed from build.
>>
>>   - xx.y  QEMU becomes a pure native rust program and all C is expunged.
>>           We may never get to this point.
>>
>> We should publish the intention and the road map prominently although it
>> was unclear if a blog post would be the best place vs expanding a
>> section in the developers manual. Perhaps both make sense with a blog
>> post for the statement of intent and rough timeline and the developer
>> manual being expanded with any new rules and standards to follow?
>>
>
> FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
> (which
> admittedly is going away) and Tier 3 for everything else.
>

oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/o hosts
and
tier 3 for aarch64 (and everything else). In FreeBSD, amd64 and aarch64 are
tier 1 supported platforms and I got those confused. It is an important
difference
and later in my email I refer to it, so I thought a correction was in order.


> There was some concern about the missing gaps in the support matrix
>> especially as we support a number of "legacy" TCG backends. While *-user
>> support is more insulated from the effects of rust conversions due to
>> its relatively low set of dependencies it will still be a problem if we
>> convert the core CPU QOM classes to rust.
>>
>
> Indeed. I have great concerns here, though we've already dropped
> 32-bit host support for bsd-user. The status of aarch64 support and rumored
> difficulty getting that rust support upgraded give me pause for concern
> because it's a FreeBSD Tier 1 platform. While it basically works, the lack
> of
> commitment by the Rust community is troubling. Even more troubling because
> rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
> being available for years at this point (though maybe this info has changed
> in the last month or two, the years long delay in moving off the interfaces
> that the FreeBSD project obsoleted about 8 years ago is troubling on its
> own).
> Much of the resistance I'm told (I'm not a big rust person, so I have to
> reply
> on others) has been in the rust team because they don't have enough
> familiarity
> with FreeBSD to make any kind of decision so even properly solved issues
> linger in the official upstream. The FreeBSD project critically depends on
> bsd-user for its release process, though that dependency so far has been
> only on x86 and aarch64, both of which work almost all the time, even if
> they aren't Tier 1 rust platforms.
>
> For -system use, this could limit where qemu runs, though to be honest
> the only platform I know has users that might be affected running -system
> might be RISCV.
>
> There's similar issues with other BSDs, but I've heard even less reliable
> information
> about them, so I'll just leave it at that.
>
> So a strawman timeline of 2 years strikes me as unrealistically agressive
> for it to be an absolute requirement given the slow rate of change I've
> seen
> with upstream rust WRT FreeBSD. At the very least, it would put qemu on
> non-x86/non-aarch64 platforms at risk. While not a huge audience, there are
> some users there. The Tier 2 status for Rust at best for FreeBSD is also a
> bit worrying for elimination of all C or a big reliance on rust in the
> core that
> can't realistically be avoided. I'm not sure this should gate the start of
> the rust
> experiment, but I raise it now so as that experiment progresses towards
> production
> people think to talk to me or others in the FreeBSD community as they
> progress.
>
> Warner
>

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

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Daniel P. Berrangé]

On Thu, Oct 03, 2024 at 02:53:08AM -0600, Warner Losh wrote:
> On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> > One output from this discussion should be a clear statement that we are
> > going forward with this work and the road map. A rough roadmap might
> > look like:
> >
> >   - 9.2   --enable-rust is available and developers can build with it.
> >           rust devices have -x-device or -rust-device CLI flags for
> >           runtime selection.
> >
> >   - 10.x  rust devices feature complete and migration compatible, enabled
> >           by default when rust compiler detected. No CLI selection
> >           required as legacy portions won't be built. Any partial
> >           conversions should be behind --enable-prototype-rust configure
> >           flag.
> >
> >   - 11.x  distros have enough infrastructure to build on supported
> >           platforms. Rust becomes a mandatory dependency, old C versions
> >           of converted code removed from build.
> >
> >   - xx.y  QEMU becomes a pure native rust program and all C is expunged.
> >           We may never get to this point.
> >
> > We should publish the intention and the road map prominently although it
> > was unclear if a blog post would be the best place vs expanding a
> > section in the developers manual. Perhaps both make sense with a blog
> > post for the statement of intent and rough timeline and the developer
> > manual being expanded with any new rules and standards to follow?
> >
> 
> FeeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
> (which
> admittedly is going away) and Tier 3 for everything else.
> 
> > There was some concern about the missing gaps in the support matrix
> > especially as we support a number of "legacy" TCG backends. While *-user
> > support is more insulated from the effects of rust conversions due to
> > its relatively low set of dependencies it will still be a problem if we
> > convert the core CPU QOM classes to rust.
> >
> 
> Indeed. I have great concerns here, though we've already dropped
> 32-bit host support for bsd-user. The status of aarch64 support and rumored
> difficulty getting that rust support upgraded give me pause for concern
> because it's a FreeBSD Tier 1 platform. While it basically works, the lack
> of commitment by the Rust community is troubling. Even more troubling because
> rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
> being available for years at this point (though maybe this info has changed
> in the last month or two, the years long delay in moving off the interfaces
> that the FreeBSD project obsoleted about 8 years ago is troubling on its
> own).
> Much of the resistance I'm told (I'm not a big rust person, so I have to
> reply on others) has been in the rust team because they don't have enough
> familiarity
> with FreeBSD to make any kind of decision so even properly solved issues
> linger in the official upstream. The FreeBSD project critically depends on
> bsd-user for its release process, though that dependency so far has been
> only on x86 and aarch64, both of which work almost all the time, even if
> they aren't Tier 1 rust platforms.

I don't think we should over-think the upstream Rust support tiers for QEMU.
Rust is one of very few OSS projects that bothers to classify platforms
they target to this degree of detail. Most OSS projects will test primarily
on Linux, and x86_64 / aarch64, with most everything else done on an adhoc
basis, relying on user feedback & patches. eg If I look at what Rust says

  "Tier 3 targets are those which the Rust codebase has support
   for, but which the Rust project does not build or test
   automatically, so they may or may not work."

I would say that describes the status of most non-Linux / non-x86/arm64
platform combinations, across a very large part of the OSS software
ecosystem, including a lot of libraries QEMU depends on.

Admittedly, compilers are the area where platform support is taken most
seriously, given they are the foundation for everything else above, and
the comparison benchmark in this case is the support matrix offered by
GCC + CLang combined which is incredibly broad. Above that though, QEMU
has a mandatory dep on Glib, and its supported & tested platform set
is massively narrower than this.

I think it is inevitable that a number of QEMU platforms we can build
on will be classified Tier 2 or even 3 by Rust upstream, as just many
libraries QEMU depends on today would effectively be "Tier 3" if their
upstream actually tried to document such details.

What I think is more important than the absolute Tier level, is whether
Rust has been ported at all to a given OS + arch combination. This is
where tier 3 guides us - an indication that there's been enough interest
in Rust for it to have been ported to that target at some point, and thus
an expectation (or hope) that it can be kept working, if there are
sufficient people downstream who care about that particular Rust target.

> For -system use, this could limit where qemu runs, though to be honest
> the only platform I know has users that might be affected running -system
> might be RISCV.
> 
> There's similar issues with other BSDs, but I've heard even less reliable
> information
> about them, so I'll just leave it at that.

In terms of QEMU upstream, we actively test FreeBSD on x86_64 in Gitlab
CI, via Cirrus, and to a slightly lesser extent test OpenBSD/NetBSD on
x86_64 with our adhoc VM environments. Anything else is delegated to
downstream users of QEMU to report bugs to us, though we try not to
take code that would obviously break other platforms even if we can't
test it ourselves. In Rust, the other BSDs are Tier 3 which is weaker
than QEMU aims for x86_64, but on a par with QEMU for non-x86

  https://doc.rust-lang.org/rustc/platform-support/netbsd.html
  https://doc.rust-lang.org/rustc/platform-support/openbsd.html

at least they have a designated developer who presumably aims to keep
those rust ports working over time.

> So a strawman timeline of 2 years strikes me as unrealistically agressive
> for it to be an absolute requirement given the slow rate of change I've seen
> with upstream rust WRT FreeBSD. At the very least, it would put qemu on
> non-x86/non-aarch64 platforms at risk. While not a huge audience, there are
> some users there. The Tier 2 status for Rust at best for FreeBSD is also a
> bit worrying for elimination of all C or a big reliance on rust in the core
> that can't realistically be avoided. I'm not sure this should gate the start
> of the rust experiment, but I raise it now so as that experiment progresses
> towards production people think to talk to me or others in the FreeBSD
> community as they progress.

I don't think being "Tier 2" is a problem - that is still a pretty strong
level of support from upstream Rust

  https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-2-target-policy

Beyond that, I don't think any of the upstream Rust tiers are neccessarily
a constraint for QEMU, even Tier 3.

IMHO what matters more is whether the OS distro in question has managed
to successfully package Rust + its stdlib in their distro, to the extent
that QEMU is able to build, using the distro provided packages.

That is the bar we have for basically every dependency we add to QEMU.
Distro support is more important that upstream support. The upstream
support is really more of an indication of how hard a life the distro
maintainer is going to have keeping it working in their distro, rather
than whether QEMU should/should not use it.

With 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 BoF and maintainer minutes and planning the roadmap to Rust

[Alex Bennée]

Warner Losh <imp@bsdimp.com> writes:

> On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <imp@bsdimp.com> wrote:
>
>  On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  One output from this discussion should be a clear statement that we are
>  going forward with this work and the road map. A rough roadmap might
>  look like:
>
>    - 9.2   --enable-rust is available and developers can build with it.
>            rust devices have -x-device or -rust-device CLI flags for
>            runtime selection.
>
>    - 10.x  rust devices feature complete and migration compatible, enabled
>            by default when rust compiler detected. No CLI selection
>            required as legacy portions won't be built. Any partial
>            conversions should be behind --enable-prototype-rust configure
>            flag.
>
>    - 11.x  distros have enough infrastructure to build on supported
>            platforms. Rust becomes a mandatory dependency, old C versions
>            of converted code removed from build.
>
>    - xx.y  QEMU becomes a pure native rust program and all C is expunged.
>            We may never get to this point.
>
>  We should publish the intention and the road map prominently although it
>  was unclear if a blog post would be the best place vs expanding a
>  section in the developers manual. Perhaps both make sense with a blog
>  post for the statement of intent and rough timeline and the developer
>  manual being expanded with any new rules and standards to follow?
>
>  FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386 (which
>  admittedly is going away) and Tier 3 for everything else.
>
> oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/o hosts and
> tier 3 for aarch64 (and everything else). In FreeBSD, amd64 and aarch64 are
> tier 1 supported platforms and I got those confused. It is an important difference
> and later in my email I refer to it, so I thought a correction was in
> order.

Are there any other big projects coming down the line that have
indicated a need for rust support? Obviously you don't have to worry
about the Linux kernel but I wonder how much rust userspace you
currently have packaged? Do you have the rust-vmm vhost-device binaries
for example?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Warner Losh]

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

On Thu, Oct 3, 2024, 3:53 AM Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Thu, Oct 03, 2024 at 02:53:08AM -0600, Warner Losh wrote:
> > On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> > > One output from this discussion should be a clear statement that we are
> > > going forward with this work and the road map. A rough roadmap might
> > > look like:
> > >
> > >   - 9.2   --enable-rust is available and developers can build with it.
> > >           rust devices have -x-device or -rust-device CLI flags for
> > >           runtime selection.
> > >
> > >   - 10.x  rust devices feature complete and migration compatible,
> enabled
> > >           by default when rust compiler detected. No CLI selection
> > >           required as legacy portions won't be built. Any partial
> > >           conversions should be behind --enable-prototype-rust
> configure
> > >           flag.
> > >
> > >   - 11.x  distros have enough infrastructure to build on supported
> > >           platforms. Rust becomes a mandatory dependency, old C
> versions
> > >           of converted code removed from build.
> > >
> > >   - xx.y  QEMU becomes a pure native rust program and all C is
> expunged.
> > >           We may never get to this point.
> > >
> > > We should publish the intention and the road map prominently although
> it
> > > was unclear if a blog post would be the best place vs expanding a
> > > section in the developers manual. Perhaps both make sense with a blog
> > > post for the statement of intent and rough timeline and the developer
> > > manual being expanded with any new rules and standards to follow?
> > >
> >
> > FeeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
> > (which
> > admittedly is going away) and Tier 3 for everything else.
> >
> > > There was some concern about the missing gaps in the support matrix
> > > especially as we support a number of "legacy" TCG backends. While
> *-user
> > > support is more insulated from the effects of rust conversions due to
> > > its relatively low set of dependencies it will still be a problem if we
> > > convert the core CPU QOM classes to rust.
> > >
> >
> > Indeed. I have great concerns here, though we've already dropped
> > 32-bit host support for bsd-user. The status of aarch64 support and
> rumored
> > difficulty getting that rust support upgraded give me pause for concern
> > because it's a FreeBSD Tier 1 platform. While it basically works, the
> lack
> > of commitment by the Rust community is troubling. Even more troubling
> because
> > rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
> > being available for years at this point (though maybe this info has
> changed
> > in the last month or two, the years long delay in moving off the
> interfaces
> > that the FreeBSD project obsoleted about 8 years ago is troubling on its
> > own).
> > Much of the resistance I'm told (I'm not a big rust person, so I have to
> > reply on others) has been in the rust team because they don't have enough
> > familiarity
> > with FreeBSD to make any kind of decision so even properly solved issues
> > linger in the official upstream. The FreeBSD project critically depends
> on
> > bsd-user for its release process, though that dependency so far has been
> > only on x86 and aarch64, both of which work almost all the time, even if
> > they aren't Tier 1 rust platforms.
>
> I don't think we should over-think the upstream Rust support tiers for
> QEMU.
> Rust is one of very few OSS projects that bothers to classify platforms
> they target to this degree of detail. Most OSS projects will test primarily
> on Linux, and x86_64 / aarch64, with most everything else done on an adhoc
> basis, relying on user feedback & patches. eg If I look at what Rust says
>
>   "Tier 3 targets are those which the Rust codebase has support
>    for, but which the Rust project does not build or test
>    automatically, so they may or may not work."
>
> I would say that describes the status of most non-Linux / non-x86/arm64
> platform combinations, across a very large part of the OSS software
> ecosystem, including a lot of libraries QEMU depends on.
>
> Admittedly, compilers are the area where platform support is taken most
> seriously, given they are the foundation for everything else above, and
> the comparison benchmark in this case is the support matrix offered by
> GCC + CLang combined which is incredibly broad. Above that though, QEMU
> has a mandatory dep on Glib, and its supported & tested platform set
> is massively narrower than this.
>
> I think it is inevitable that a number of QEMU platforms we can build
> on will be classified Tier 2 or even 3 by Rust upstream, as just many
> libraries QEMU depends on today would effectively be "Tier 3" if their
> upstream actually tried to document such details.
>
> What I think is more important than the absolute Tier level, is whether
> Rust has been ported at all to a given OS + arch combination. This is
> where tier 3 guides us - an indication that there's been enough interest
> in Rust for it to have been ported to that target at some point, and thus
> an expectation (or hope) that it can be kept working, if there are
> sufficient people downstream who care about that particular Rust target.
>
> > For -system use, this could limit where qemu runs, though to be honest
> > the only platform I know has users that might be affected running -system
> > might be RISCV.
> >
> > There's similar issues with other BSDs, but I've heard even less reliable
> > information
> > about them, so I'll just leave it at that.
>
> In terms of QEMU upstream, we actively test FreeBSD on x86_64 in Gitlab
> CI, via Cirrus, and to a slightly lesser extent test OpenBSD/NetBSD on
> x86_64 with our adhoc VM environments. Anything else is delegated to
> downstream users of QEMU to report bugs to us, though we try not to
> take code that would obviously break other platforms even if we can't
> test it ourselves. In Rust, the other BSDs are Tier 3 which is weaker
> than QEMU aims for x86_64, but on a par with QEMU for non-x86
>
>   https://doc.rust-lang.org/rustc/platform-support/netbsd.html
>   https://doc.rust-lang.org/rustc/platform-support/openbsd.html
>
> at least they have a designated developer who presumably aims to keep
> those rust ports working over time.
>
> > So a strawman timeline of 2 years strikes me as unrealistically agressive
> > for it to be an absolute requirement given the slow rate of change I've
> seen
> > with upstream rust WRT FreeBSD. At the very least, it would put qemu on
> > non-x86/non-aarch64 platforms at risk. While not a huge audience, there
> are
> > some users there. The Tier 2 status for Rust at best for FreeBSD is also
> a
> > bit worrying for elimination of all C or a big reliance on rust in the
> core
> > that can't realistically be avoided. I'm not sure this should gate the
> start
> > of the rust experiment, but I raise it now so as that experiment
> progresses
> > towards production people think to talk to me or others in the FreeBSD
> > community as they progress.
>
> I don't think being "Tier 2" is a problem - that is still a pretty strong
> level of support from upstream Rust
>
>
> https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-2-target-policy
>
> Beyond that, I don't think any of the upstream Rust tiers are neccessarily
> a constraint for QEMU, even Tier 3.
>
> IMHO what matters more is whether the OS distro in question has managed
> to successfully package Rust + its stdlib in their distro, to the extent
> that QEMU is able to build, using the distro provided packages.
>

Those have been hit or miss for anything not amd64 or aarch64 on FreeBSD.
Sometimes they work, sometimes not. But rust support requires special weird
kernel options to work at all... so the situation on FreeBSD is more wobbly
than you'd otherwise think. We'll see how it evolves, but an 6-8 year lag
in upstream support even though community members contrivuted better
support at least 4 years ago is a clear red flashing light of caution.
Though unlikely, there is a risk that the root cause of this problem causes
things to degrade more. And then FreeBSD would fail the supplied packages
test. Use this info as you will, but don't just dismiss it out of hand.
There is a long history here of unusual friction that rises to the level of
concern I won't be brushed off with assurances you don't think it will be a
problem.

Warner

That is the bar we have for basically every dependency we add to QEMU.
> Distro support is more important that upstream support. The upstream
> support is really more of an indication of how hard a life the distro
> maintainer is going to have keeping it working in their distro, rather
> than whether QEMU should/should not use it.
>
> With 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 :|
>
>

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

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Daniel P. Berrangé]

On Thu, Oct 03, 2024 at 02:53:08AM -0600, Warner Losh wrote:

> commitment by the Rust community is troubling. Even more troubling because
> rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
> being available for years at this point (though maybe this info has changed
> in the last month or two, the years long delay in moving off the interfaces
> that the FreeBSD project obsoleted about 8 years ago is troubling on its
> own).

Is this problem resolved by this change updating to FreeBSD 12 ABI:

  https://github.com/rust-lang/libc/pull/3434

Or is there more beyond that which remains an issue ?

Also what's the best source of truth about Rust support in FreeBSD 
eg I see this:

  https://wiki.freebsd.org/Rust

 Reports i386, amd64, armv6, armv7, aarch64, power64, power64le
 and riscv64

and then this

  https://www.freshports.org/lang/rust

but doesn't say anything about riscv64, and armv6/i386 is listed as
"N/A" for FreeBSD 15 - are those arches no longer supported in 15 ?

power64le is outdated there compared to other arches

With 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 BoF and maintainer minutes and planning the roadmap to Rust

[Michael Tokarev]

03.10.2024 12:56, Alex Bennée wrote:
...
> Are there any other big projects coming down the line that have
> indicated a need for rust support? Obviously you don't have to worry
> about the Linux kernel but I wonder how much rust userspace you
> currently have packaged? Do you have the rust-vmm vhost-device binaries
> for example?

FWIW, rust-vmm only supports 64bit hosts.  They explicitly refuse patches
to address issues on 32bits.

/mjt

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Warner Losh]

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

[[ sorry for the lag $LIFE has been over-full lately ]]

On Thu, Oct 3, 2024 at 3:56 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> Warner Losh <imp@bsdimp.com> writes:
>
> > On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <imp@bsdimp.com> wrote:
> >
> >  On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> >  One output from this discussion should be a clear statement that we are
> >  going forward with this work and the road map. A rough roadmap might
> >  look like:
> >
> >    - 9.2   --enable-rust is available and developers can build with it.
> >            rust devices have -x-device or -rust-device CLI flags for
> >            runtime selection.
> >
> >    - 10.x  rust devices feature complete and migration compatible,
> enabled
> >            by default when rust compiler detected. No CLI selection
> >            required as legacy portions won't be built. Any partial
> >            conversions should be behind --enable-prototype-rust configure
> >            flag.
> >
> >    - 11.x  distros have enough infrastructure to build on supported
> >            platforms. Rust becomes a mandatory dependency, old C versions
> >            of converted code removed from build.
> >
> >    - xx.y  QEMU becomes a pure native rust program and all C is expunged.
> >            We may never get to this point.
> >
> >  We should publish the intention and the road map prominently although it
> >  was unclear if a blog post would be the best place vs expanding a
> >  section in the developers manual. Perhaps both make sense with a blog
> >  post for the statement of intent and rough timeline and the developer
> >  manual being expanded with any new rules and standards to follow?
> >
> >  FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
> (which
> >  admittedly is going away) and Tier 3 for everything else.
> >
> > oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/o
> hosts and
> > tier 3 for aarch64 (and everything else). In FreeBSD, amd64 and aarch64
> are
> > tier 1 supported platforms and I got those confused. It is an important
> difference
> > and later in my email I refer to it, so I thought a correction was in
> > order.
>
> Are there any other big projects coming down the line that have
> indicated a need for rust support?


There's a few things that may happen to help drive rust. People
have written a few things in rust that they hope to make default
once FreeBSD finishes its transition to pkgbase (though that's some
time in the future). There's also a desire to experiment with rust drivers
in the kernel for more fringe features to see if that helps us get done
faster.


> Obviously you don't have to worry
> about the Linux kernel but I wonder how much rust userspace you
> currently have packaged? Do you have the rust-vmm vhost-device binaries
> for example?
>

Yes. I believe we build those today.

I expect it to mostly work, most of the time, to be honest on FreeBSD. I
also
expect there to be more breakage than we see with llvm/clang...

So the bottom line should be that we'll be able to make it work, but there
is likely going to be more work since rust is less mature than C. However,
it's not clear if this is an occasional minor thing, or if it becomes major
and
frequent. And the only way to know that is to take the plunge, so don't
let this stop your plans.

Warner

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

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Alex Bennée]

Warner Losh <imp@bsdimp.com> writes:

> [[ sorry for the lag $LIFE has been over-full lately ]]

No worries.
>  
>  Obviously you don't have to worry
>  about the Linux kernel but I wonder how much rust userspace you
>  currently have packaged? Do you have the rust-vmm vhost-device binaries
>  for example?
>
> Yes. I believe we build those today.
>
> I expect it to mostly work, most of the time, to be honest on FreeBSD. I also
> expect there to be more breakage than we see with llvm/clang...

I would hope if llvm/clang is working you shouldn't see any additional
breakage due to rust (I don't believe they overly hack llvm for their
use).

> So the bottom line should be that we'll be able to make it work, but there
> is likely going to be more work since rust is less mature than C. However,
> it's not clear if this is an occasional minor thing, or if it becomes major and
> frequent. And the only way to know that is to take the plunge, so don't
> let this stop your plans.

Absolutely. The aim of this exercise was to make sure downstreams are
aware this is coming so it doesn't come as a surprise. I did CC
emulation at freebsd but I got bounced as I was not subscribed. Could
you make the wider FreeBSD community aware of the thread?

>
> Warner

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Paolo Bonzini]

Since I wasn't able to attend the BOF, I delayed my reply until after
I could get some experience with Manos's code and make a list of
things to do in the immediate future. I think my recent patches reach
the point at which the work can be parallelized (and a list of
subsequent steps are at https://wiki.qemu.org/RustInQemu#TODO).

On Thu, Sep 26, 2024 at 4:23 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> During the various conversations I didn't hear anyone speak against the
> proposed migration although some concerns where raised about review and
> knowledge gaps.

Yes, I agree.

> One output from this discussion should be a clear statement that we are
> going forward with this work and the road map. A rough roadmap might
> look like:
>
>   - 9.2   --enable-rust is available and developers can build with it.
>           rust devices have -x-device or -rust-device CLI flags for
>           runtime selection.
>
>   - 10.x  rust devices feature complete and migration compatible, enabled
>           by default when rust compiler detected. No CLI selection
>           required as legacy portions won't be built. Any partial
>           conversions should be behind --enable-prototype-rust configure
>           flag.
>
>   - 11.x  distros have enough infrastructure to build on supported
>           platforms. Rust becomes a mandatory dependency, old C versions
>           of converted code removed from build.

Here is my version:

9.2
--enable-rust is available and developers can build with it. Ideally
this results in feature parity, but we cannot yet be sure that this is
the case. (Current holes are documented in
https://wiki.qemu.org/RustInQemu#TODO)

10.x
--enable-rust is default.
Duplicates of existing code are allowed in order to gain experience
with the creation of bindings to C code, but should (probably must)
have feature parity with C code.
It is possible to build Rust devices that have a limited amount of
unsafe code in the device itself, especially during runtime as opposed
to initialization.

11.x
--enable-rust is mandatory and disabling it will drop support for
devices or boards.

> We should publish the intention and the road map prominently although it
> was unclear if a blog post would be the best place vs expanding a
> section in the developers manual. Perhaps both make sense with a blog
> post for the statement of intent and rough timeline and the developer
> manual being expanded with any new rules and standards to follow?

Agreed. The blog post should also document some of the design decisions.

> There was some concern about the missing gaps in the support matrix
> especially as we support a number of "legacy" TCG backends. While *-user
> support is more insulated from the effects of rust conversions due to
> its relatively low set of dependencies it will still be a problem if we
> convert the core CPU QOM classes to rust.
>
> In theory if LLVM supports the architecture we should be able to
> generate binaries with a rust compiler although we may not have all
> tools available on that host.

Yeah, based on the detection code that we added in "configure", it
seems that LLVM (and Rust) supports all of the targets in our support
matrix?

> Hanna and Stefan were keen to see more use of Rust in the block layer.
> Hanna cautioned that it was hard to find a reasonable starting point for
> the conversion. Originally she had started with the core sub-system but
> it quickly ran into thousands of lines of code which would be hard to
> get well reviewed before switching for such a crucial sub-system. Maybe
> this is an ordering problem and it would make more sense to start with
> individual block drivers first and work up from there.
>
> Alex mentioned softfloat could make a good candidate for conversion as
> while the rewrite had made things easier to follow and extend there were
> still some C macro tricks employed to get code re-use. It would depend
> on if Rust's macro and trait system allows more of the common logic to
> be kept together.
>
> The qboot firmware for MicroVM's was also mentioned as a potential
> candidate.

I am not sure of the benefits there. qboot has a bunch of hand-crafted
C macros to work in 16-bit mode, and does not even have a free()
function (it does have malloc() though). Rewriting qboot code in Rust
is unlikely teach us many lessons that are useful for the rest of
QEMU, and would not have substantial benefits in terms of memory
safety.

> With relative inexperience there was a concern we could inadvertently
> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> What can we do to mitigate that issue?

My main suggestion is to take it slowly. While the recent flurry of
posted patches may suggest otherwise, a lot of those were developed
over several months (sometimes years!) and the posted version is not
the first.

The other suggestion is for reviewers to not be afraid to say "I have
no idea what you're doing". If a reviewer does not understand how the
language is being used, the affected code must either have a clear
documentation explaining the design, or be rewritten.

Of course core bindings code will be more complex/complicated than we
all wish, but the important thing is to _absolutely_ get public APIs
right. Private implementation details can be subject to future
evolution and cleanup, while public APIs are much harder to change.
That said:

- bad public APIs tend to be larger red flags of technical debt in
Rust than in C

- we can look at what other projects (especially Linux) are doing, and
use that to make informed decisions. There aren't many projects doing
integration of Rust into massive C code bases, but we are not first.

- many of our core APIs (chardev, memory region ops, timers, etc.) are
fairly stable

- there are several patterns that are common across QEMU code (for
example Error**, or vtables), and therefore experience writing one set
of C<->Rust bindings will help with other areas of the code as well.

Things may be different in other areas. For example, block devices may
also suffer impedance mismatch between Rust async/await and C
coroutines.

> We make heavy use of GLib throughout the code base and while new Rust
> code should use native structures for arrays and the like there are
> places when Glib structures are passed across API boundaries. Should we
> consider updating APIs as we go or live with a degree of thunking until
> we have a better idea where the pain points are?

I think that's relatively rare and we can cross that bridge when we
get there. The glib_rs crate exists, but I don't really like its
design, because it's very much tuned towards cloning C data to
Rust-managed memory and it hides the performance characteristics of
code that uses it. But if all we need is GArray/GPtrArray/GByteArray,
there's not a lot of code to write and there's no need for thunking.

That said, C<->Rust interoperability is something that has to be
tackled sooner or later for objects such as Error. I have my favored
approach (https://lore.kernel.org/r/all/20240701145853.1394967-4-pbonzini@redhat.com/)
but it's not an easy subject. Again, let's take it slowly. It's okay
if the first devices cannot have a realize() function that fails, just
because we haven't figured out Error yet.

> One of the promises of Rust is its support for inline unit test
> integration although there was a little confusion about how this works
> in practice. Are separate test binaries created with just the code under
> test or is there a unit testable build of QEMU itself? Does this still
> work with mixed C and Rust code?

The posted patches have examples of both unit- and integration-testing
of Rust code.

> It was suggested creating a qemu-rust mailing list that all patches that
> touch or introduce rust could Cc. This would help those willing to
> review rust find patches without having to wade through the qemu-devel
> firehose.

Good idea, who does it? :)

> Some distros do allow exceptions for "vendoring"
> dependencies as part of the build but it is generally discouraged. [...]
> The general consensus seemed to be we should be fairly conservative
> about adding new crate dependencies while the Rust ecosystem in distros
> matures. While we should support rustup/cargo installed tools so
> developers can build and test on existing LTS distros we should be
> aiming to build QEMU without downloading any additional packages. There
> may be some flexibility for build-only dependencies (c.f. our pyenv) but
> runtime dependencies should be served by the distro itself.

Note that this is _not_ what we are doing right now. All dependent
crates are vendored and included in the QEMU tarball. However, this is
also why we are very conservative about adding new crates. Right now
it's basically only "bilge" and its dependency "arbitrary-int", a
crate for "readable bitfields".

Thanks for writing this down!

Paolo

Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Paolo Bonzini]

On 9/27/24 09:28, Markus Armbruster wrote:
> A deliberate approach to explore some before we go all in could mitigate
> the risk of taking on too much technical debt.
> 
> We obviously need to write instances of each interesting class of things
> to ferret out the problems, and design good interfaces.  I'd recommend
> to write few instances, ideally one, then let them mature some before we
> create many more of them.  Prioritize gaining experience over quantity.
The "first" device to be written in Rust, pl011, will already require 
developing C<->Rust interoperability for QOM, device properties, 
character devices and memory region operations.  The first two are there 
only in an embryonic state (the bare minimum required to create a QOM 
class in Rust) and the other two don't exist at all.

I agree with you we should prioritize gaining experience in those four 
areas, over writing many more Rust devices.

Paolo