Re: [PATCH v5 1/2] crosvm: add recipe for ChromeOS Virtual Machine Monitor (VMM)

Hi Keerthivasan,

Inline review of 1/2. Same caveat as on the cover: if any of these are
already addressed in your v1 (which I can't see), please ignore and
let me know.

On Thu, May 28, 2026 at 00:40 +0530, Keerthivasan Raghavan wrote:
> crosvm is a lightweight, Rust-based virtual
> machine monitor originally developed for ChromeOS,
> and provides an alternative to traditional VMMs such
> as QEMU.
> 
> Signed-off-by: Keerthivasan Raghavan <[email protected]>
> ---
>  recipes-devtools/crosvm/crosvm-crates.inc | 966 ++++++++++++++++++++++
>  recipes-devtools/crosvm/crosvm_0.1.0.bb   |  57 ++
>  2 files changed, 1023 insertions(+)
>  create mode 100644 recipes-devtools/crosvm/crosvm-crates.inc
>  create mode 100644 recipes-devtools/crosvm/crosvm_0.1.0.bb
> 
> diff --git a/recipes-devtools/crosvm/crosvm-crates.inc b/recipes-devtools/crosvm/crosvm-crates.inc
> [... 966 lines of autogenerated crates.inc elided ...]
> diff --git a/recipes-devtools/crosvm/crosvm_0.1.0.bb b/recipes-devtools/crosvm/crosvm_0.1.0.bb
> new file mode 100644
> index 00000000..00b492b0
> --- /dev/null
> +++ b/recipes-devtools/crosvm/crosvm_0.1.0.bb
> @@ -0,0 +1,57 @@
> +SUMMARY = "crosvm is a secure, lightweight, and performant Virtual Machine Monitor (VMM) written in Rust."
> +
> +DESCRIPTION = "\
> +crosvm is a Rust-based virtual machine monitor (VMM) originally developed \
> +for ChromeOS. It uses KVM acceleration and process-level isolation to run guest VMs \
> +with sandboxed device emulation.\
> +"
> +
> +HOMEPAGE = "https://github.com/google/crosvm"
> +
> +LICENSE = "BSD-3-Clause-Clear"
> +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/BSD-3-Clause-Clear;md5=7a434440b651f4a472ca93716d01033a"
> +
> +inherit cargo pkgconfig cargo-update-recipe-crates features_check
> +
> +SRC_URI = " \
> +    git://chromium.googlesource.com/crosvm/crosvm.git;branch=main;protocol=https;name=crosvm \
> +    git://chromium.googlesource.com/chromiumos/platform/minijail;branch=main;protocol=https;name=minijail;destsuffix=${BB_GIT_DEFAULT_DESTSUFFIX}/third_party/minijail \
> +"
> +
> +SRCREV_crosvm = "b04c13a65b93034010b20612e3566d4f9d83c4f0"
> +SRCREV_minijail = "bfd22f25fd2302fe4ae5121d80c836e0f124e742"
> +
> +SRCREV_FORMAT = "crosvm_minijail"
> +
> +PV = "0.1.0+git"
> +
> +DEPENDS += "libcap wayland wayland-native protobuf-native wayland-protocols"
> +
> +REQUIRED_DISTRO_FEATURES = "kvm"
> +
> +COMPATIBLE_HOST = "(aarch64|x86_64).*-linux.*"
> +
> +BBCLASSEXTEND = "native"
> +
> +# cargo.bbclass adds SRC_URI entries with "name" and "destsuffix" to
> +# ${CARGO_HOME}/config.toml as Cargo patches. It uses the SRC_URI path as-is
> +# and does not account for "subdir".
> +# This can make Cargo try to build a directory that has no Cargo.toml. Remove
> +# the generated entry from ${CARGO_HOME}/config.toml. The crosvm Cargo.toml
> +# already points to the correct patch path relative to the source root.
> +do_filter_minijail_cargo_config() {
> +
> +    cfg="${CARGO_HOME}/config.toml"
> +
> +    if [ ! -f "$cfg" ]; then
> +        bbwarn "Skipping missing Cargo config: $cfg"
> +        exit 0
> +    fi
> +
> +    bbnote "Processing Cargo config: $cfg"
> +    sed -i '/minijail/d' "$cfg"
> +}
> +
> +addtask filter_minijail_cargo_config after do_configure before do_compile
> +
> +require crosvm-crates.inc

A few things:

1. recipes-devtools/ vs recipes-extended/

The other VMMs in this layer (libvirt, xen, xen-tools) all live under
recipes-extended/. recipes-devtools/ in meta-virt is mostly go-mod
tooling (go, go-distribution, etc.). crosvm fits the VMM category, so
recipes-extended/crosvm/ would match convention better.

Not strictly blocking, but worth moving in v2 (or whatever the next
spin is called).

2. do_filter_minijail_cargo_config — root cause, please

The recipe carries this workaround:

> +do_filter_minijail_cargo_config() {
> +    cfg="${CARGO_HOME}/config.toml"
> +    if [ ! -f "$cfg" ]; then
> +        bbwarn "Skipping missing Cargo config: $cfg"
> +        exit 0
> +    fi
> +    bbnote "Processing Cargo config: $cfg"
> +    sed -i '/minijail/d' "$cfg"
> +}
> +addtask filter_minijail_cargo_config after do_configure before do_compile

The comment says cargo.bbclass writes a [patches.crates-io] entry to
${CARGO_HOME}/config.toml using the SRC_URI path as-is, without
honouring the "subdir=" in your minijail SRC_URI entry. So cargo tries
to build a path that has no Cargo.toml and fails.

This concerns me because meta-virt has a number of other cargo
recipes — netavark, aardvark-dns, podlet, fuse-overlayfs — and none
of them carry an equivalent workaround. So either:

  a) they all benefit from the same problem somehow (e.g. their
     SRC_URI entries don't use subdir=), or

  b) they do trigger the same cargo.bbclass behaviour but happen to
     not break because their secondary repos do contain a Cargo.toml
     at the SRC_URI root, or

  c) cargo.bbclass has been fixed in oe-core master since this recipe
     was written, and the workaround is now stale.

Could you dig into the root cause and confirm which of (a/b/c) applies?
If (c), we can just drop the workaround. If (a) or (b), the fix
probably belongs in cargo.bbclass upstream — and we'd carry a
documented local workaround until that lands, rather than a sed-script
postfunc with no commentary on why it's needed only for crosvm.

3. SRC_URI source

> +    git://chromium.googlesource.com/crosvm/crosvm.git;branch=main;protocol=https;name=crosvm \

chromium.googlesource.com is the canonical source. The
github.com/google/crosvm mirror is typically more reliable from a
yocto build infrastructure standpoint (the chromium.org hosts have
periodically been touchy with cgit-style fetches for me in the past).
Did you consider the github mirror? If there's a reason chromium is
preferred (e.g. it gets fixes first, or has signed tags), worth a
one-line comment in the recipe.

4. PV = "0.1.0+git"

> +PV = "0.1.0+git"

crosvm doesn't tag releases, so "0.1.0" is arbitrary. That's fine —
we have precedent in the layer (kvmtool's PV is similarly cosmetic).
Just calling it out so we don't get bug reports asking why we're
shipping a "0.1.0" of a project that has never had a 1.0.

5. BBCLASSEXTEND = "native"

> +BBCLASSEXTEND = "native"

Per offline discussion with you previously, I understand this is for
a future "runqemu"-like runner that can boot a guest from a host
build. Nothing to do today; leave it.

Bruce