Re: [RFC PATCH 0/8] i386/sev: Use C API of Rust SEV library

[Daniel P . Berrangé]

On Thu, Sep 14, 2023 at 01:58:27PM -0400, Tyler Fanelli wrote:
> These patches are submitted as an RFC mainly because I'm a relative
> newcomer to QEMU with no knowledge of the community's views on
> including Rust code, nor it's preference of using library APIs for
> ioctls that were previously implemented in QEMU directly.

We've talked about Rust alot, but thus far most focus has been on
areas peripheral to QEMU. Projects that might have been part of
QEMU in the past, and now being done as separate efforts, and
have bene taking advantage of Rust. eg virtiofsd Rust replacing
QEMU's in -tree C impl. eg passt providing an alternative to
slirp. eg the dbus display in QEMU allowing a remote display
frontend to be provided, written in rust. eg libblkio providing
a block backend in Rust.

The libblkio work is likely closest to what you've proposed
here, in that it is a Rust create exposed as a C shared library
for apps to consume. In theory apps don't need to care that it
is written in Rust, as it is opaque.

The one key difference though is that it was not replacing
existing functionality, it was adding a new feature. So users
who didn't have libblkio or whom want to avoid Rust dependancies
didn't loose anything they were already using.

If we use the libsev.so we create a hard dependancy on the Rust
sev crate, otherwise users loose the SEV feature in QEMU. Right
now the sev crate C library is not present in *any* distro that
I can see.

If we treat 'sev' as just another opaque 3rd party library to be
provided by the distro, this creates a problem. Our support
policy is that we usually won't drop features in existing distros,
but that is what would happen if we applied this patchset today.
We did bend that rule slightly with virtiofsd, but that was already
a separate binary and we followed our deprecation path before
deleting it, giving distros time to adapt.


If we rollback the curtain, however, and decide to expose Rust
directly to QEMU we could address this problem. We could bundle
the dependant Rust crates directly with QEMU tarballs, and
generate the FFI C library as part of QEMU build and static
link the library. Distros would not have todo anything, though
they could have the choice of dyn linking if they really wanted
to.

If we directly exposed the notion of Rust to QEMU, then we are
also not limited by whether a Rust crate provides a C FFI itself.
QEMU could provide C FFI glue for any Rust crate it sees as
useful to its code.

This all forces us, however, to have the difficult discussion
about whether we're willing to make Rust a mandatory dependancy
of QEMU and permit (or even welcome) its use /anywhere/ in the
QEMU tree that looks relevant.

We've already queried whether Rust will actually benefit the
core QEMU codebase, or whether we'll end up punching too many
holes in its safety net to make it worthwhile. My opinion is
that we probably shouldn't obsess over that as I think it is
hard to predict the future, it has a habit of surprising us.
Your patch series here doesn't demonstrate an obvious safety
benefit, since we have existing working code and that code is
not especially complex. Once we open the doors to Rust code
in QEMU though, we will probably surprise ourselves with the
range of benefits we'll see 2, 3, 5 years down the road.

IOW, we shouldn't judge future benefits based on this patch
series. It is great that this series is actually quite simple,
because it lets us focus on how we might integrate Rust more
directly into QEMU, without worrying much about the actual
code being replaced.

> This series looks to explore the possibility of using the library and
> show a bit of what it would look like. I'm looking for comments
> regarding if this feature is desired.

My summary, is that I'd personally be in favour of opening the door
to Rust code as a mandatory pre-requisite for QEMU, at the very least
for system emulators. Not because this particular series is compelling,
but because I think Rust could be more beneficial to QEMU over the long
term than we expect. In terms of consuming it though, if we're going
to replace existing QEMU functionality, then I think we need to bundle
the Rust code and natively integrate it into the build system, as we
have recently started doing with our python deps, to detach ourselves
from the limits of what distros ship.

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