Can someone familiar with this code add some unit-tests for this repository? I am required to add some tests for the backend device part in https://github.com/rust-vmm/vhost-device/ and not very sure of how to add those ..

This commit requires one to implement the new 'get_inflight_fd' and 'set_inflight_fd' functions for VhostUserHandler from the VhostUserSlaveReqHandlerMut trait. The following error occurs otherwise:

error[E0046]: not all trait items implemented, missing: `get_inflight_fd`, `set_inflight_fd`
   --> /home/hvub/.cargo/git/checkouts/vhost-user-backend-0d66fc5baaf39798/ddc7dd5/src/lib.rs:556:1
    |
556 | impl<S: VhostUserBackend> VhostUserSlaveReqHandlerMut for VhostUserHandler<S> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `get_inflight_fd`, `set_inflight_fd` in implementation
    |
    = help: implement the missing item: `fn get_inflight_fd(&mut self, _: &VhostUserInflight) -> std::result::Result<(VhostUserInflight, i32), vhost::vhost_user::Error> { todo!() }`
    = help: implement the missing item: `fn set_inflight_fd(&mut self, _: &VhostUserInflight, _: File) -> std::result::Result<(), vhost::vhost_user::Error> { todo!() }`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0046`.
error: could not compile `vhost-user-backend`

To learn more, run the command again with --verbose.

Is anybody working on implementing this? If not, I could give it a shot.

Now that virtio-queue 0.3.0 has been released, we should update the vhost-user-backend accordingly.

Could someone tag a new release for the vhost-user-backend crate so that Cloud Hypervisor can rely on it rather than using the latest commit from the main branch?
Apart from that, given that there are plans to update/simplify virtio-queue, this might/will bring breaking changes, therefore it might be a good idea to tag a release before virtio-queue is getting updated.

I've enabled the CI for this component, and it currently has two fails:

• one is the coverage; we need to add a coverage_config_x86_64.json file in the root of the project; you can find an example in rust-vmm-ci; Once you add the file, you can run the coverage test to see the coverage score by:

docker run --device=/dev/kvm -it --security-opt seccomp=unconfined --volume $(pwd):/vhost-user-backend rustvmm/dev:v11
cd vhost-user-backend
pytest pytest rust-vmm-ci/integration_tests/test_coverage.py

# In case you want to check the test report, you can run the coverage test with --no-cleanup as follows:
# pytest pytest rust-vmm-ci/integration_tests/test_coverage.py --no-cleanup

• aarch64-musl build failing; you'll need this commit: rust-vmm/vm-virtio@9d31dc0

The build fails with the following error:

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
   --> cargo/git/checkouts/vhost-1b8454ea45823bbf/e4ba734/src/vhost_user/connection.rs:303:26
    |
303 |         let (bytes, _) = self.sock.recv_with_fds(&mut iovs, &mut [])?;
    |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function

We should mark the call as unsafe and specify why is the way we are calling this function safe.

I noticed that this crate already has vmm-sys-util as a dependency, so I was wondering if we could also use the epoll module from vmm-sys-util instead of importing another external crate.

@slp it looks like this crate does not run tests on each PR. The rust-vmm-ci does not seem to be properly initialized as a submodule. Is there another CI that's running?

Dependabot couldn't find the submodule rust-vmm-ci. Perhaps it isn't committed, or isn't a submodule?

View the update logs.

Hi,

A lot of this is almost certainly down to my lack of experience with Rust but it can't hurt to improve the documentation on usage.

Can vhost-user-backend be used in a single-threaded daemon?

As I understand it the Send/Sync traits are all about how to deal with concurrency for the struct. Does this mean you have to spawn additional threads for each request being serviced or can you have a simple single-threaded daemon?

Which method do incoming vhost-user messages arrive at?

I thought it was handle_event but the comments imply this is for specific FD's and not the standard vhost-user FD. A rough outline of the main message loop would be helpful here.

Can you point to any canonical use cases of vhost-user-backend?

I'm familiar with the virtiofsd daemon but it has a lot going on. A list of other known users of the crate would help in seeing example use and how to plumb things together.

Thanks.

MockSplitQueues, available in the virtio-queue crate, allows for the testing of vring operations by implementing the virtio backend side of the equation. Key to that concept is the sharing of the memory used by the Queues, something that is currently not possible since the VringT trait does not have a function to create a new element from a Queue. Something like:

let mem = GuestMemoryAtomic::new(
GuestMemoryMmap::<()>::from_ranges(&[(GuestAddress(0x100000), 0x10000)]).unwrap(),
);

let vq = MockSplitQueue::new(&mem, 16);
let q = vq.create_queue(mem);
let vring = VringRwLock::new(q, 16);

That way DescriptorChains can be inserted in @vq and processed from @VRing. An example of how DescriptorChains can be created and inserted in the MockSplitQueue can be found here.

For all that to work the VringState will also need to be created from an existing Queue and the GuestMemory trait implemented for GuestMemoryAtomic<GuestMemoryMmap>.

This is moved to https://github.com/rust-vmm/vhost now, lets make it deprecated now.

@andreeaflorescu @jiangliu

I think this might be due to an update in one of the dependencies: https://buildkite.com/rust-vmm/vhost-user-backend-ci/builds/184. We've updated the way we specify dependencies in vm-memory, virtio-queue, and vmm-sys-util. We should also sue caret dependencies in this crate as well to avoid failures.

Failed build: https://buildkite.com/rust-vmm/vhost-user-backend-ci/builds/184

I guess this might be a wider policy question but when implementing a new daemon should we have a way to enable logging in the backend crate. At the moment I'm stuck trying to diagnose where in the vhost-user sequence something is missing by using gdb. Perhaps we should use log! macros so debug builds can be more verbose if required?

Using the latest virtio-queue revision is the first step in allowing crates that include vhost-user-backend to test different Mutex/RwLockVring manipulations. The MockSplitQueue implements the virtio backend side of the equation and is able to insert DescriptorChains in the VringMutex/RwLocks. Those are then processed by the handle_event() method of types that implement the VhostUserBackend and VhostUserBackendMut traits.