ccaf8c56bf
Converting arbitrary bytes into an arbitrary Rust value is unsafe. For example, it's unsafe to create a String that isn't valid UTF-8. But the various internal recv* functions didn't restrict their return types enough to enforce this invariant, making them unsafe without being properly marked. To fix this, we tighten up the bounds of the functions to enforce that their return types are ByteValued, meaning that they can only be used to create types that are safe to initialize with arbitrary data such as might be received over a socket. It's worth asking how these functions could have been unsafe in the first place, since they don't contain any unsafe blocks themselves. The answer is that the functions that recv into iovecs are also unsafe but not correctly marked. I'm preparing further patches to fix that up, but it's a lot of work so I've separated out this change in the hope of getting it in first and making the diff for the next one smaller. This internal tightening shouldn't result in any public API changes. Signed-off-by: Alyssa Ross <hi@alyssa.is> |
||
|---|---|---|
| .buildkite | ||
| .cargo | ||
| .github | ||
| docs | ||
| rust-vmm-ci@a00c7d2f1b | ||
| src | ||
| .gitignore | ||
| .gitmodules | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| CODEOWNERS | ||
| coverage_config_aarch64.json | ||
| coverage_config_x86_64.json | ||
| LICENSE | ||
| LICENSE-BSD-Google | ||
| README.md | ||
vHost
A pure rust library for vDPA, vhost and vhost-user.
The vhost crate aims to help implementing dataplane for virtio backend drivers. It supports three different types of dataplane drivers:
- vhost: the dataplane is implemented by linux kernel
- vhost-user: the dataplane is implemented by dedicated vhost-user servers
- vDPA(vhost DataPath Accelerator): the dataplane is implemented by hardwares
The main relationship among Traits and Structs exported by the vhost crate is as below:
Kernel-based vHost Backend Drivers
The vhost drivers in Linux provide in-kernel virtio device emulation. Normally the hypervisor userspace process emulates I/O accesses from the guest. Vhost puts virtio emulation code into the kernel, taking hypervisor userspace out of the picture. This allows device emulation code to directly call into kernel subsystems instead of performing system calls from userspace. The hypervisor relies on ioctl based interfaces to control those in-kernel vhost drivers, such as vhost-net, vhost-scsi and vhost-vsock etc.
vHost-user Backend Drivers
The vhost-user protocol aims to implement vhost backend drivers in userspace, which complements the ioctl interface used to control the vhost implementation in the Linux kernel. It implements the control plane needed to establish virtqueue sharing with a user space process on the same host. It uses communication over a Unix domain socket to share file descriptors in the ancillary data of the message.
The protocol defines two sides of the communication, master and slave. Master is the application that shares its virtqueues, slave is the consumer of the virtqueues. Master and slave can be either a client (i.e. connecting) or server (listening) in the socket communication.