On Mon, 10 Jun 2024 at 14:23, Manos Pitsidianakis <manos.pitsidiana...@linaro.org> wrote: > > Hello everyone, > > This is an early draft of my work on implementing a very simple device, > in this case the ARM PL011 (which in C code resides in hw/char/pl011.c > and is used in hw/arm/virt.c). > > The device is functional, with copied logic from the C code but with > effort not to make a direct C to Rust translation. In other words, do > not write Rust as a C developer would. > > That goal is not complete but a best-effort case. To give a specific > example, register values are typed but interrupt bit flags are not (but > could be). I will leave such minutiae for later iterations. > > By the way, the wiki page for Rust was revived to keep track of all > current series on the mailing list https://wiki.qemu.org/RustInQemu > > a #qemu-rust IRC channel was also created for rust-specific discussion > that might flood #qemu > > ------------------------------------------------------------------------ > A request: keep comments to Rust in relation to the QEMU project and no > debates on the merits of the language itself. These are valid concerns, > but it'd be better if they were on separate mailing list threads. > ------------------------------------------------------------------------ > > Table of contents: [TOC] > > - How can I try it? [howcanItryit] > - What are the most important points to focus on, at this point? > [whatarethemostimportant] > - What are the issues with not using the compiler, rustc, directly? > [whataretheissueswith] > 1. Tooling > 2. Rust dependencies > > - Should QEMU use third-party dependencies? [shouldqemuusethirdparty] > - Should QEMU provide wrapping Rust APIs over QEMU internals? > [qemuprovidewrappingrustapis] > - Will QEMU now depend on Rust and thus not build on my XYZ platform? > [qemudependonrustnotbuildonxyz] > - How is the compilation structured? [howisthecompilationstructured] > - The generated.rs rust file includes a bunch of junk definitions? > [generatedrsincludesjunk] > - The staticlib artifact contains a bunch of mangled .o objects? > [staticlibmangledobjects] > > How can I try it? > ================= > [howcanItryit] Back to [TOC] > > Hopefully applying this patches (or checking out `master` branch from > https://gitlab.com/epilys/rust-for-qemu/ current commit > de81929e0e9d470deac2c6b449b7a5183325e7ee ) > > Tag for this RFC is rust-pl011-rfc-v1 > > Rustdoc documentation is hosted on > > https://rust-for-qemu-epilys-aebb06ca9f9adfe6584811c14ae44156501d935ba4.gitlab.io/pl011/index.html > > If `cargo` and `bindgen` is installed in your system, you should be able > to build qemu-system-aarch64 with configure flag --enable-rust and > launch an arm virt VM. One of the patches hardcodes the default UART of > the machine to the Rust one, so if something goes wrong you will see it > upon launching qemu-system-aarch64. > > To confirm it is there for sure, run e.g. info qom-tree on the monitor > and look for x-pl011-rust. > > > What are the most important points to focus on, at this point? > ============================================================== > [whatarethemostimportant] Back to [TOC] > > In my opinion, integration of the go-to Rust build system (Cargo and > crates.io) with the build system we use in QEMU. This is "easily" done > in some definition of the word with a python wrapper script. > > What are the issues with not using the compiler, rustc, directly? > ----------------------------------------------------------------- > [whataretheissueswith] Back to [TOC] > > 1. Tooling > Mostly writing up the build-sys tooling to do so. Ideally we'd > compile everything without cargo but rustc directly.
Why would that be ideal? > > If we decide we need Rust's `std` library support, we could > investigate whether building it from scratch is a good solution. This > will only build the bits we need in our devices. Whether or not to use std is a fundamental decision. It might be difficult to back from std later on. This is something that should be discussed in more detail. Do you want to avoid std for maximum flexibility in the future, or are there QEMU use cases today where std is unavailable? > > 2. Rust dependencies > We could go without them completely. I chose deliberately to include > one dependency in my UART implementation, `bilge`[0], because it has > an elegant way of representing typed bitfields for the UART's > registers. > > [0]: Article: https://hecatia-elegua.github.io/blog/no-more-bit-fiddling/ > Crates.io page: https://crates.io/crates/bilge > Repository: https://github.com/hecatia-elegua/bilge I guess there will be interest in using rust-vmm crates in some way. Bindings to platform features that are not available in core or std will also be desirable. We probably don't want to reinvent them. > > Should QEMU use third-party dependencies? > ----------------------------------------- > [shouldqemuusethirdparty] Back to [TOC] > > In my personal opinion, if we need a dependency we need a strong > argument for it. A dependency needs a trusted upstream source, a QEMU > maintainer to make sure it us up-to-date in QEMU etc. > > We already fetch some projects with meson subprojects, so this is not a > new reality. Cargo allows you to define "locked" dependencies which is > the same as only fetching specific commits by SHA. No suspicious > tarballs, and no disappearing dependencies a la left-pad in npm. > > However, I believe it's worth considering vendoring every dependency by > default, if they prove to be few, for the sake of having a local QEMU > git clone buildable without network access. Do you mean vendoring by committing them to qemu.git or just the practice of running `cargo vendor` locally for users who decide they want to keep a copy of the dependencies? > > Should QEMU provide wrapping Rust APIs over QEMU internals? > ----------------------------------------------------------- > [qemuprovidewrappingrustapis] Back to [TOC] > > My personal opinion is no, with the reasoning being that QEMU internals > are not documented or stable. However I do not see why creating stable > opt-in interfaces is bad. It just needs someone to volunteer to maintain > it and ensure there are no breakages through versions. Rust code will need to interface with QEMU's C APIs, so Rust wrappers seem unavoidable. Using a protocol like vhost-user might be possible in some cases. It separates the two codebases so they can both be native and without bindings, but that won't work for all parts of the QEMU source tree. Stable APIs aren't necessary if most developers in the QEMU community are willing to work in both languages. They can adjust both C and Rust code when making changes to APIs. I find this preferable to having Rust maintainers whose job is to keep wrappers up-to-date. Those Rust maintainers would probably burn out. This seems like a question of which approach the developer community is comfortable with. > > Will QEMU now depend on Rust and thus not build on my XYZ platform? > ------------------------------------------------------------------- > [qemudependonrustnotbuildonxyz] Back to [TOC] > > No, worry about this in some years if this experiment takes off. Rust > has broad platform support and is present in most distro package > managers. In the future we might have gcc support for it as well. > > For now, Rust will have an experimental status, and will be aimed to > those who wish to try it. I leave it to the project leaders to make > proper decisions and statements on this if necessary. This can be discussed in a separate email thread if you prefer, but I do think it needs agreement soon so that people have the confidence to invest their time in writing Rust. They need to know that the code they develop will be available on most platforms where QEMU is available and that others in the community won't object or insist on a C implementation for platform support reasons. > > > How is the compilation structured? > ================================== > [howisthecompilationstructured] Back to [TOC] > > First, a meson target that runs `bindgen` on a bunch of header files > (defined in `rust/wrapper.h`) is created as a target and as a dependency > for any rust hardware device that needs it. You can see the generated > bindings by running > > ninja generated.rs > > inside your build directory. > > The devices are defined as dictionaries in rust/meson.build because they > depend on the bindgen dependency, which is available much later in the > meson process (when the static qemu lib and target emulator executables > are defined). > > A cargo wrapper python script under scripts/ exists to build the crate > library, by providing the path to the generated.rs bindings via the > environment. Then, the qemu-system-aarch64 binary links against the > staticlib archive (i.e. libpl011.a) > > The generated.rs rust file includes a bunch of junk definitions? > ================================================================ > [generatedrsincludesjunk] Back to [TOC] > > Yes, bindgen allows you to block certain types and identifiers from > being generated but they are simply too many. I have trimmed some of the > fat but vast improvements can be made. > > The staticlib artifact contains a bunch of mangled .o objects? > ============================================================== > [staticlibmangledobjects] Back to [TOC] > > Yes, until we compile without the `std` module library or we compile it > manually instead of linking it, we will have some junk in it. What is the consequence of this? As long as the linker is bringing in .o files from the .a only through symbol dependencies, then unused .o files in the .a won't be linked into the final QEMU binary. > > -- > > Manos Pitsidianakis (6): > build-sys: Add rust feature option > rust: add PL011 device model > DO NOT MERGE: add rustdoc build for gitlab pages > DO NOT MERGE: replace TYPE_PL011 with x-pl011-rust in arm virt machine > rust: add bindgen step as a meson dependency > DO NOT MERGE: update rustdoc gitlab pages gen > > .gitignore | 2 + > .gitlab-ci.d/buildtest.yml | 64 ++-- > configure | 12 + > hw/arm/virt.c | 2 +- > meson.build | 99 ++++++ > meson_options.txt | 4 + > rust/meson.build | 93 ++++++ > rust/pl011/.cargo/config.toml | 2 + > rust/pl011/.gitignore | 2 + > rust/pl011/Cargo.lock | 120 +++++++ > rust/pl011/Cargo.toml | 26 ++ > rust/pl011/README.md | 42 +++ > rust/pl011/build.rs | 44 +++ > rust/pl011/meson.build | 7 + > rust/pl011/rustfmt.toml | 10 + > rust/pl011/src/definitions.rs | 95 ++++++ > rust/pl011/src/device.rs | 531 ++++++++++++++++++++++++++++++ > rust/pl011/src/device_class.rs | 95 ++++++ > rust/pl011/src/generated.rs | 5 + > rust/pl011/src/lib.rs | 575 +++++++++++++++++++++++++++++++++ > rust/pl011/src/memory_ops.rs | 38 +++ > rust/wrapper.h | 39 +++ > scripts/cargo_wrapper.py | 221 +++++++++++++ > scripts/meson-buildoptions.sh | 5 + > 24 files changed, 2113 insertions(+), 20 deletions(-) > create mode 100644 rust/meson.build > create mode 100644 rust/pl011/.cargo/config.toml > create mode 100644 rust/pl011/.gitignore > create mode 100644 rust/pl011/Cargo.lock > create mode 100644 rust/pl011/Cargo.toml > create mode 100644 rust/pl011/README.md > create mode 100644 rust/pl011/build.rs > create mode 100644 rust/pl011/meson.build > create mode 100644 rust/pl011/rustfmt.toml > create mode 100644 rust/pl011/src/definitions.rs > create mode 100644 rust/pl011/src/device.rs > create mode 100644 rust/pl011/src/device_class.rs > create mode 100644 rust/pl011/src/generated.rs > create mode 100644 rust/pl011/src/lib.rs > create mode 100644 rust/pl011/src/memory_ops.rs > create mode 100644 rust/wrapper.h > create mode 100644 scripts/cargo_wrapper.py > > > base-commit: 01782d6b294f95bcde334386f0aaac593cd28c0d > -- > γαῖα πυρί μιχθήτω > >
