pxcloud/vhost-device
5
0
Fork 0
mirror of https://github.com/rust-vmm/vhost-device.git synced 2025-12-27 15:45:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
906 Commits 2 Branches 19 Tags 5.3 MiB
Rust 98.4%
C 1.2%
Roff 0.3%
Shell 0.1%
09e9da304c
Go to file
Stefano Garzarella 09e9da304c vsock: avoid circular references 
We have the following circular references found by Li Zebin:
    VhostUserBackend ==> VhostUserVsockThread ==> VringEpollHandler

In addition to causing a resource leak, this causes also an error
after we merged commit 38caab2 ("vsock: Don't allow duplicate CIDs").
When the VM reboot or shutdown, the application exits with the
following error:

    [ERROR vhost_device_vsock] Could not create backend:
        CID already in use by another vsock device

This happened because we have these circular references and
VhostUserVsockThread::drop() is never invoked. So, we don't remove
the cid from the map.

Let's fix this problem by simply removing the reference to
VringEpollHandler from VhostUserVsockThread. In fact, we do not
need to keep the reference for the lifetime of VhostUserVsockThread,
as we only need to add the handlers once.

Let's also rename the fields to follow the current VhostUserDaemon
API.

Closes #438

Reported-by: Li Zebin <cutelizebin@gmail.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
2023-10-27 16:13:37 +05:30
.buildkite staging: add custom pipelines to run CI tests 2023-10-17 16:35:55 +05:30
.cargo Ignore advisory: RUSTSEC-2021-0145 2022-11-30 12:01:14 +05:30
.github dependabot: enable update grouping 2023-10-06 12:58:11 +05:30
rust-vmm-ci@0b9e2e28ba Bump rust-vmm-ci manually to use rustvmm/dev:v28 2023-10-26 15:07:38 +05:30
staging sound: Implement RX in ALSA backend 2023-10-27 11:39:04 +01:00
vhost-device-gpio Move all crates to workspace root 2023-10-16 12:03:57 +05:30
vhost-device-i2c Move all crates to workspace root 2023-10-16 12:03:57 +05:30
vhost-device-rng Move all crates to workspace root 2023-10-16 12:03:57 +05:30
vhost-device-scmi Move all crates to workspace root 2023-10-16 12:03:57 +05:30
vhost-device-scsi Move all crates to workspace root 2023-10-16 12:03:57 +05:30
vhost-device-vsock vsock: avoid circular references 2023-10-27 16:13:37 +05:30
.gitignore Add .gitignore 2021-08-19 09:52:14 +03:00
.gitmodules Initial commit 2021-05-26 10:18:40 +03:00
Cargo.lock build(deps): bump the vhost-device group with 4 updates 2023-10-23 11:50:23 +05:30
Cargo.toml Move all crates to workspace root 2023-10-16 12:03:57 +05:30
CODEOWNERS CODEOWNERS: add stefano-garzarella 2022-10-13 09:41:24 +02:00
coverage_config_x86_64.json tests: adjust code coverage after tool updates 2023-09-13 15:58:52 +01:00
LICENSE-APACHE Initial commit 2021-05-26 10:18:40 +03:00
LICENSE-BSD-3-Clause Add BSD-3-Clause license for the crates 2022-10-27 11:19:40 -06:00
README.md video: initial skeleton 2023-10-24 11:17:33 +02:00

README.md

vhost-device

Design

This repository hosts various 'vhost-user' device backends in their own crates. See their individual README.md files for specific information about those crates.

To be included here device backends must:

Here is the list of device backends that we support:

Staging Devices

Implementing a proper VirtIO device requires co-ordination between the specification, drivers and backend implementations. As these can all be in flux during development it was decided introducing a staging workspace which would allow developers to work within the main rust-vmm project while clearly marking the backends as not production ready.

To be included in the staging workspace there must at least be:

  • A public proposal to extend the VIRTIO specification
  • A public implementation of a device driver
  • Documentation pointing to the above

More information may be found in its README file.

Here is the list of device backends in staging:

Testing and Code Coverage

Like the wider rust-vmm project we expect new features to come with comprehensive code coverage. However as a multi-binary repository there are cases where avoiding a drop in coverage can be hard and an exception to the approach is allowable. These are:

  • adding a new binary target (aim at least 60% overall coverage)
  • expanding the main function (a small drop is acceptable)

However any new feature added to an existing binary should not cause a drop in coverage. The general aim should be to always improve coverage.

Separation of Concerns

The binaries built by this repository can be run with any VMM which can act as a vhost-user frontend. Typically they have been tested with QEMU although the rust-vmm project does provide a vhost-user frontend crate for rust based VMMs.

While it's possible to implement all parts of the backend inside the vhost-device workspace consideration should be given to separating the VirtQueue handling and response logic to a crate in vm-virtio devices. This way a monolithic rust-vmm VMM implementation can reuse the core logic to service the virtio requests directly in the application.

Build dependency

The GPIO crate needs a local installation of libgpiod library to be available. If your distro ships libgpiod >= v2.0, then you should be fine.

Otherwise, you will need to build libgpiod yourself:

git clone --depth 1 --branch v2.0.x https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
cd libgpiod
./autogen.sh --prefix="$PWD/install/"
make install

In order to inform tools about the build location, you can now set:

export PKG_CONFIG_PATH="<PATH-TO-LIBGPIOD>/install/lib/pkgconfig/"

To prevent setting this in every terminal session, you can also configure cargo to set it automatically.

Xen support

Supporting Xen requires special handling while mapping the guest memory. The vm-memory crate implements xen memory mapping support via a separate feature xen, and this crate uses the same feature name to enable Xen support.

It was decided by the rust-vmm maintainers to keep the interface simple and build the crate for either standard Unix memory mapping or Xen, and not both.