Go to file
dependabot[bot] bcde6e7c4d
build(deps): bump proc-macro2 from 1.0.30 to 1.0.32
Bumps [proc-macro2](https://github.com/dtolnay/proc-macro2) from 1.0.30 to 1.0.32.
- [Release notes](https://github.com/dtolnay/proc-macro2/releases)
- [Commits](https://github.com/dtolnay/proc-macro2/compare/1.0.30...1.0.32)

---
updated-dependencies:
- dependency-name: proc-macro2
  dependency-type: indirect
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
2021-11-15 12:27:47 +00:00
.cargo Initial commit 2021-05-26 10:18:40 +03:00
.github dependabot: Allow updating dependencies 2021-09-06 12:54:53 +05:30
rust-vmm-ci@b037be3396 build(deps): bump rust-vmm-ci from 7931077 to b037be3 2021-11-01 10:45:12 +02:00
src/i2c i2c: Remove unused mem field 2021-11-08 09:30:22 +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 proc-macro2 from 1.0.30 to 1.0.32 2021-11-15 12:27:47 +00:00
Cargo.toml Convert to virtual manifest and add i2c workspace 2021-08-19 09:52:14 +03:00
CODEOWNERS CODEOWNERS: add myself an Mathieu to aid review 2021-11-09 10:02:30 +02:00
coverage_config_x86_64.json [i2c] Update coverage score and Cargo.lock 2021-10-27 12:38:09 +05:30
LICENSE-APACHE Initial commit 2021-05-26 10:18:40 +03:00
README.md README.md: document aim for separating concerns 2021-11-09 10:02:30 +02:00

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.

Here is the list of device backends that we support:

Separation of Concerns

The binaries built by this repository can be run with any VMM which can act as a vhost-user master. Typically they have been tested with QEMU although the rust-vmm project does provide a vhost-user master 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.