mirror of
https://chromium.googlesource.com/crosvm/crosvm
synced 2025-02-10 12:09:31 +00:00
5b456d31f9
When vhost-user front-end send a vhost-user message via Unix domain socket, a message header is sent first with optional attached files. Then, a message body is sent as a separate packet if necessary. However, the existing implementation blocks only before a message header coming and assumed that the message body is ready when the header comes. So, there was a race and `handle_request` could return `EAGAIN`. This CL splits SlaveReqHandler::handle_request() into recv_header() and process_message() so a caller can wait between the header and the additional payload. On VVU, we shouldn't wait before receiving the payloads because the proxy device forwards a header and its message body together. So we check the protocol in needs_wait_for_payload(). BUG=b:237891754 TEST=Run vhost-user block on Linux TEST=Run vhost-user block on Windows TEST=Run VVU block on Linux Change-Id: I35af3eb0e706cb005bf697397698e01e272b0704 Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3863050 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Alexandre Courbot <acourbot@chromium.org> Reviewed-by: Noah Gold <nkgold@google.com> Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org> |
||
|---|---|---|
| .. | ||
| .buildkite | ||
| .cargo | ||
| .github | ||
| docs | ||
| src | ||
| .gitignore | ||
| .gitmodules | ||
| Cargo.toml | ||
| CODEOWNERS | ||
| LICENSE | ||
| LICENSE-BSD-3-Clause | ||
| LICENSE-BSD-Chromium | ||
| README.md | ||
vHost
A pure rust library for vhost-user. This is a fork of rust-vmm/vhost.
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.