The new clippy in rust-vmm-ci complain about this:
error: doc list item missing indentation
--> vhost/src/vhost_user/connection.rs:305:9
|
305 | /// In other words, recvmsg() operations must not cross the packet boundary, other...
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
= note: `-D clippy::doc-lazy-continuation` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::doc_lazy_continuation)]`
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
The new clippy in rust-vmm-ci complain about this:
error: match can be simplified with `.unwrap_or_default()`
--> vhost/src/vhost_user/connection.rs:138:20
|
138 | let rfds = match fds {
| ____________________^
139 | | Some(rfds) => rfds,
140 | | _ => &[],
141 | | };
| |_________^ help: replace it with: `fds.unwrap_or_default()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_unwrap_or_default
= note: `-D clippy::manual-unwrap-or-default` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::manual_unwrap_or_default)]`
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
The latest toolchain update in rust-vmm-ci caused the following
error:
error: unexpected `cfg` condition value: `cargo-clippy`
--> vhost/src/vhost_user/message.rs:758:16
|
758 | #[cfg_attr(feature = "cargo-clippy", allow(clippy::useless_conversion))]
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
As suggested in [1], today is no longer needed to check the
`cargo-clippy` feature (which has been deprecated), but we can
just use `#[allow(clippy::lint_name)]`.
[1] https://blog.rust-lang.org/2024/02/28/Clippy-deprecating-feature-cargo-clippy.html
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Add methods to send cursor related messages: VHOST_USER_GPU_CURSOR_POS,
VHOST_USER_GPU_CURSOR_POS_HIDE and VHOST_USER_GPU_CURSOR_UPDATE.
VhostUserGpuCursorUpdate's `data` field is passed as a separate argument
into cursor_update method. The type is also an u8 array instead of u32
array like in the spec. Having the type be u8 array makes it easier to work
with the data without unsafe code for the consumer of this crate. Having it
be a separate argument is useful, because the user of the method doesn't
have to copy the array into a struct.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Add get_protocol_features method to send
VHOST_USER_GPU_GET_PROTOCOL_FEATURES and receive the reply. Also add
a method to send SET_PROTOCOL_FEATURES.
Introduce VhostUserGpuProtocolFeatures bitmap that defines possible feature
flags.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Add methods and related structs to send the VHOST_USER_GPU_DMABUF_SCANOUT
and VHOST_USER_GPU_DMABUF_UPDATE update messages.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
Add a method and related struct to send VHOST_USER_GPU_UPDATE.
The data part of the message is not part of the struct like sugested by
the spec but a separate argument to update_scanout. This is necessary
because of limitations of having an unsized array inside of struct in Rust.
But this aproach seems preferable anyway, because it allows the consumer of
the crate to store the array in a diferent location than the struct.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Signed-off-by: Matej Hrica <mhrica@redhat.com>
Add a get_display_info() method and the related reply structs to send
VHOST_USER_GPU_GET_DISPLAY_INFO and receive the reply.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Signed-off-by: Matej Hrica <mhrica@redhat.com>
Introduce another constant MAX_MSG_SIZE that is part of the MsgHeader
trait. For now this is only used for sending messages.
Consider using the more specific trait constant everywhere.
The VHOST_USER_GPU_UPDATE and VHOST_USER_GPU_CURSOR_UPDATE contain image
data and are larger than the existing MAX_MSG_SIZE.
The existing MAX_MSG_SIZE wasn't really a limitation of the protocol,
just an implementation detail limitation in this crate.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
The VHOST_USER_GPU_SET_SOCKET is only handled when the feature gpu-socket
is enabled. This also introduces a GpuBackend for handling comunication
over the socket.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
This commit adds the basic definitions of GPU commands on the socket
obtained from VHOST_USER_GPU_SET_SOCKET. This also introduces a new
feature flag `gpu-socket` in the vhost crate.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
Move the enum_value macro into vhost_user module and make it public within
this module. This will be used in the next commit for defining gpu message
enum.
Signed-off-by: Matej Hrica <mhrica@redhat.com>
The Endpoint was previusly generic only over the Request.
This commit allows Endpoint to be used with a protocol with a slightly
different header such as the QEMU GPU protocol on the socket from
VHOST_USER_GPU_SET_SOCKET.
https://www.qemu.org/docs/master/interop/vhost-user-gpu.html
Signed-off-by: Matej Hrica <mhrica@redhat.com>
virtiofsd 1.11.0 added support for VHOST_USER_PROTOCOL_F_DEVICE_STATE.
Upgrading virtiofsd meant that the latest released version of Cloud
Hypervisor (39.0) was no longer able to communicate with it, because
rather than just ignoring the unsupported feature, it got an
unrecoverable "invalid message" error. This demonstrates that it's
better for frontends to just ignore offers of unsupported features.
If the backend requires some feature, it'll get a chance to know that
when we send VHOST_USER_SET_PROTOCOL_FEATURES anyway.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Since these non-standard backend request
message types are confirmed not to be used
anymore, let's just remove them.
```
pub enum BackendReq {
...
/// Virtio-fs draft: map file content into the window.
FS_MAP = 100,
/// Virtio-fs draft: unmap file content from the window.
FS_UNMAP = 1001,
/// Virtio-fs draft: sync file content.
FS_SYNC = 1002,
/// Virtio-fs draft: perform a read/write from an fd directly to GPA.
FS_IO = 1003,
...
}
```
Closes: #213
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Check for VHOST_USER_PROTOCOL_F_SHARED_OBJECT flag
before allowing the backend to send SHARED_OBJECT_*
requests.
If it does have negotiated the protocol feature,
avoid sending the message and return error code
(i.e., !=0).
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Add SHARED_OBJECT_* vhost-user request
IDs to align with standard. Implement
backend functions to send these
requests.
Add SHARED_OBJECT protocol feature.
Add GET_SHARED_OBJECT to the frontend
requests (not implemented, this is just to
have the placeholder and align with current
standard).
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Assertion fails on the frontend thread in tests
can go unnoticed.
To avoid that the main thread finishes before
and solve this issue, let's `join()` the thread
at the end of the test.
Signed-off-by: Albert Esteve <aesteve@redhat.com>
FS_* vhost-user backend request messages in
BackendReq enum did not make it into the
standard yet. Actually, currently there
are already SHARED_OBJECT_* messages that
use the message type IDs for FS_* types.
To fix this and avoid the issue for future
message IDs, let's move FS_* types further
away and prevent collision to occur.
This way we only need to change it once.
Signed-off-by: Albert Esteve <aesteve@redhat.com>
A frontend can skip the call to set_vring_base, assuming the ring will
be initialized at 0. If that frontend acknowledge EVENT_IDX vring and
VhostUserHandler backend will never know they need to use event idx.
Move the features configuration of the vring and the backend to set_features method.
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
This release adds support for live migration, adding
dirty pages tracking and initial postcopy support.
Signed-off-by: German Maglione <gmaglione@redhat.com>
This release adds support for live migration, adding
dirty pages tracking and initial postcopy support.
Signed-off-by: German Maglione <gmaglione@redhat.com>
If the backend has the VHOST_USER_PROTOCOL_F_LOG_SHMFD protocol feature
it will receive the VHOST_USER_SET_LOG_BASE message with a file
descriptor of the dirty-pages log memory region. This log covers all
known guest addresses, and must be manipulated atomically.
For further info please see
https://qemu-project.gitlab.io/qemu/interop/vhost-user.html#migration
Signed-off-by: German Maglione <gmaglione@redhat.com>
Any bitmap used in the vhost-user backend must implement the
BitmapReplace trait, which provides the functionality to replace the
internal bitmap in runtime.
This internal bitmap is required because in the vm-memory crate the
bitmap is expected to exist at the time of creating the memory regions,
and in the case of vhost-user the bitmap is added at runtime, also it
could be replaced at a later time. In addition, the vhost user protocol
does not specify whether the previous bitmap is still active after
replying to the VHOST_USER_SET_LOG_BASE message, so we must be sure
that the in-flight requests are using the new bitmap after the message
reply.
Signed-off-by: German Maglione <gmaglione@redhat.com>
The vhost user protocol supports live migration, and during live
migration, the vhost-user frontend needs to track the modifications the
vhost-user backend makes to the memory mapped regions, marking the
dirty pages in a log (i.e., a bitmap).
If the backend has the VHOST_USER_PROTOCOL_F_LOG_SHMFD protocol feature
it will receive the VHOST_USER_SET_LOG_BASE message with a file
descriptor of the dirty-pages log memory region. This log covers all
known guest addresses, and must be manipulated atomically.
For further info please see
https://qemu-project.gitlab.io/qemu/interop/vhost-user.html#migration
This commit adds support for creating an atomic-memory-mapped bitmap,
and being able to replace it in runtime. The vhost user protocol does
not specify whether the previous bitmap is still active after replying
to the VHOST_USER_SET_LOG_BASE message, so we use an RwLock to be sure
that the in-flight requests are using the new bitmap after the message
reply.
Signed-off-by: German Maglione <gmaglione@redhat.com>
New sections in README files describe what `postcopy`
feature enables and the limitation of using it with
`xen` feature.
Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Additional tests that trigger postcopy messages handling
on both frontend and backend side. To run successfully
they need access to /dev/userfaultfd.
Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
New feature `postcopy` is introduced. It acts as a gate for a
new functionality.
This feature is not compatible with `xen` feature because `xen`
can map memory regions on demand and this does not work with uffd.
Now backend handler supports processing of POSTCOPY messages.
This is only available when `xen` feature is not in use.
Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
