Skip to content

Conversation

epilys
Copy link
Contributor

@epilys epilys commented Jun 13, 2025

Currently, when we initialize a device, we do not conform to section 6.1 of the VIRTIO spec.

It says:

6.1 Driver Requirements: Reserved Feature Bits
A driver MUST accept VIRTIO_F_VERSION_1 if it is offered.

To fix conformance, check for presence of the VIRTIO_F_VERSION_1 and accept it if it's offered, always.

This is because not only the requirement is a MUST but also a device may fail to operate if it's not accepted:

6.2 Device Requirements: Reserved Feature Bits

A device MUST offer VIRTIO_F_VERSION_1. A device MAY fail to operate further if VIRTIO_F_VERSION_1 is not accepted.

This bug was encountered in COQOS hypervisor which failed with:

E: 6.1 Driver MUST accept VIRTIO_F_VERSION_1.

@epilys
Copy link
Contributor Author

epilys commented Jun 13, 2025

@qwandor CI for aarch64 succeeded but the logs show the vsock server panicked and because it was in the shell's background, the CI did not fail:

2025-06-13T10:56:44.8900578Z (cd ../vsock_server && cargo build --release)
2025-06-13T10:56:44.9571882Z     Updating crates.io index
2025-06-13T10:56:45.0032525Z      Locking 7 packages to latest compatible versions
2025-06-13T10:56:45.0044888Z       Adding vsock v0.3.0 (available: v0.5.1)
2025-06-13T10:56:45.0050336Z  Downloading crates ...
2025-06-13T10:56:45.0263740Z   Downloaded bitflags v1.3.2
2025-06-13T10:56:45.0300991Z   Downloaded memoffset v0.6.5
2025-06-13T10:56:45.0329370Z   Downloaded vsock v0.3.0
2025-06-13T10:56:45.0376895Z   Downloaded nix v0.24.3
2025-06-13T10:56:45.0499698Z   Downloaded libc v0.2.172
2025-06-13T10:56:45.0987662Z    Compiling autocfg v1.4.0
2025-06-13T10:56:45.0988104Z    Compiling libc v0.2.172
2025-06-13T10:56:45.0988473Z    Compiling bitflags v1.3.2
2025-06-13T10:56:45.0988858Z    Compiling cfg-if v1.0.1
2025-06-13T10:56:45.2727187Z    Compiling memoffset v0.6.5
2025-06-13T10:56:46.2364008Z    Compiling nix v0.24.3
2025-06-13T10:56:48.2755798Z    Compiling vsock v0.3.0
2025-06-13T10:56:48.8624583Z    Compiling vsock_server v0.1.0 (/home/runner/work/virtio-drivers/virtio-drivers/examples/vsock_server)
2025-06-13T10:56:49.0325721Z     Finished `release` profile [optimized] target(s) in 4.10s
2025-06-13T10:56:49.0374255Z ../vsock_server/target/release/vsock_server &
2025-06-13T10:56:49.0383168Z qemu-system-aarch64 \
2025-06-13T10:56:49.0383603Z   -display none -audiodev none,id=audio0 \
2025-06-13T10:56:49.0386197Z 	-machine virt \
2025-06-13T10:56:49.0386883Z 	-cpu max \
2025-06-13T10:56:49.0387189Z 	-serial chardev:char0 \
2025-06-13T10:56:49.0388871Z 	-kernel target/aarch64-unknown-none/release/aarch64_qemu.bin \
2025-06-13T10:56:49.0389485Z 	-global virtio-mmio.force-legacy=false \
2025-06-13T10:56:49.0389899Z 	-nic none \
2025-06-13T10:56:49.0390407Z 	-drive file=target/aarch64-unknown-none/release/img,if=none,format=raw,id=x0 \
2025-06-13T10:56:49.0391675Z 	-device vhost-vsock-device,id=virtiosocket0,guest-cid=102 \
2025-06-13T10:56:49.0392234Z 	-device virtio-blk-device,drive=x0 \
2025-06-13T10:56:49.0392643Z 	-device virtio-rng-device \
2025-06-13T10:56:49.0393030Z 	-device virtio-gpu-device \
2025-06-13T10:56:49.0393423Z 	-device virtio-serial,id=virtio-serial0 \
2025-06-13T10:56:49.0393862Z 	-chardev stdio,id=char0,mux=on \
2025-06-13T10:56:49.0394257Z 	-device virtconsole,chardev=char0
2025-06-13T10:56:49.0394696Z [Host] Setting up listening socket on port 1221
2025-06-13T10:56:49.0773193Z 
2025-06-13T10:56:49.0773510Z thread 'main' panicked at src/main.rs:13:10:
2025-06-13T10:56:49.0774347Z Failed to set up listening port: Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }
2025-06-13T10:56:49.0775314Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Currently, when we initialize a device, we do not conform to section 6.1
of the VIRTIO spec.

It says:

> 6.1 Driver Requirements: Reserved Feature Bits
> A driver MUST accept VIRTIO_F_VERSION_1 if it is offered.

To fix conformance, check for presence of the VIRTIO_F_VERSION_1 and
accept it if it's offered, always.

Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
@epilys epilys force-pushed the accept-version1-feature-bit branch from a834f9d to 1ddff95 Compare June 18, 2025 08:06
@epilys epilys requested a review from qwandor June 18, 2025 08:06
Copy link
Collaborator

@qwandor qwandor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but I'm not sure why the tests are hanging.

@qwandor
Copy link
Collaborator

qwandor commented Jun 18, 2025

The test failures do seem legitimate, I can reproduce it locally. Running QEMU_ARGS="-display none -audiodev none,id=audio0" make qemu accel="off" from examples/riscv consistently hangs with this change and runs successfully without it. I don't understand why.

@epilys
Copy link
Contributor Author

epilys commented Jun 18, 2025

I guess the examples were relying on legacy device behavior, and switching to modern virtio changed something on the QEMU side? I can have a look when I have spare time. Did you see what device causes this by any chance?

@epilys
Copy link
Contributor Author

epilys commented Jun 19, 2025

By removing the version 1 feature bit from Network's supported_features, the tests don't block. I'm looking into it to see if it's a qemu bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants