8cb0b09bec
The PullAssigner bot [1] will pick 2 github handles from the gate keepers list [2] and assign them for reviewing any new PR. The bot goes uses a round robin algorithm to select handles from the list. What happens when the CODEOWNERS file gets populated with real owners? Following the PR review and approval process [3], the PullAssigner bot will either pick only one or zero reviewers from the gate keepers list, if the CODEOWNERS file points to exactly one or more than one actual ownwer, respectively. [1] https://pullpanda.com/assigner [2] https://github.com/rust-vmm/community/blob/master/GATEKEEPERS.md [3] https://github.com/rust-vmm/community#pr-review-and-approval Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> |
||
|---|---|---|
| src | ||
| .gitignore | ||
| .travis.yml | ||
| Cargo.toml | ||
| CODEOWNERS | ||
| LICENSE | ||
| README.md | ||
vHost
A crate to implement the vHost ioctl interfaces and vHost-user protocol.
vHost Ioctl Interfaces
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 Protocol
The vHost-user protocol is aiming to complement 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.