Instruct the docs.rs documentation builder to pass --cfg
RUTSDOC_disable_feature_compat_errors in RUSTFLAGS when building
documentation, so that builds dont fail because of compile_error!() and
incompatible features [1].
[1]: https://docs.rs/crate/vhost/0.14.0/builds/2193201
Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
Introduce a dummy feature to hack around `cargo doc --all-features`
always hitting the compile_error!(...) in vhost/src/lib.rs about
incompatible features.
This is happening because when documenting vhost-user-backend, cargo
does not pass --cfg doc to dependencies, meaning the cfg(not(doc))
attribute that is supposed to eliminate this compile_error!() invokation
when building docs does not actually trigger. Hence cargo doc fails.
Introduce a custom cfg, which we tell docs.rs to set during
documentation build, which disables the compile_error!(). Our CI also
sets this flag for the rustdoc step (via an ugly `sed` in the pipeline
definition). This cfg is also set by rust-vmm-ci for the cargo doc step.
Note that we need both cfg(not(doc)) and
cfg(not(RUTSDOC_disable_feature_compat_errors)), because lib.rs gets
processed twice, onces by rustc (where the --cfg is passed via
RUSTFLAGS), and once by rustdoc itself, where RUSTFLAGS are ignored, and
instead the cfg(doc) macro comes into play (but rustdoc is only ran on
the crate for which we are actually generating docs, not the
dependencies).
Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
Set it up so that it does not try to combine the xen and postcopy
features, and also ignore the test-only test_utils feature.
Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
The vhost-device devices all call VhostUserDaemon::serve in a loop, to
handle reconnections. This is not ideal, because a new listener is
created each loop iteration, which means that each time, the old
socket is unlinked and a new one is created. This means that there's
a potential race where a frontend attempts to connect to the backend
before the new socket is created.
A more robust way to achieve this would be to have the devices create
their own listeners, and pass the same one to VhostUserDaemon::start
on each loop iteration, instead of letting VhostUserDaemon::serve
create it repeatedly. This was not previously possible though,
because VhostUserDaemon::start consumed the listener, even though it
didn't need to.
Because it's now possible to call VhostUserDaemon::start multiple
times with the same socket, I've removed the TODO about handling
reconnection.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Eventfd is Linux-specific. To support more platforms, we replace it with
the EventNotifier/EventConsumer abstractions.
EventSender and EventReceiver are wrappers that encapsulate eventfd functionality
Use pipefd to replace eventfd in the test.
Signed-off-by: Wenyu Huang <huangwenyuu@outlook.com>
clippy in the new rust toolchain (1.87) in our CI is highlighting
something to improve.
Mostly done with `cargo clippy --fix` + silence
`clippy::match_overlapping_arm` since EWOULDBLOCK equals to EGAIN on
linux.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
There is a new warning reported by nightly compiler about mismatched
lifetime syntaxes. Add the missing lifetime where ever required.
Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
This release
1. Adds support for `VHOST_USER_GET_SHARED_OBJECT`
2. Updates to vhost to 0.14.0, vm-memory 0.16.2 and vmm-sys-util to
0.14.0
Signed-off-by: Babis Chalios <bchalios@amazon.es>
This release:
1. Adds support for `VHOST_USER_GET_SHARED_OBJECT`
2. Fixes the reply header for an error case in POSTCOPY_ADVISE
3. `VHOST_USER_PROTOCOL_F_REPLY_ACK` is now always supported by backends
4. Bumps vm-memory to 0.16.2 and vmm-sys-util to 0.14.0
Signed-off-by: Babis Chalios <bchalios@amazon.es>
I observed hangs in the following situation when using Cloud
Hypervisor with virtiofsd:
1. Start virtiofsd
2. Start Cloud Hypervisor instance 1, connected to virtiofsd.
3. Start Cloud Hypervisor instance 2, waiting for migration.
4. Migrate VM from Cloud Hypervisor instance 1 to 2.
5. Start virtiofsd again.
The hangs happened because Cloud Hypervisor remembered, as part of the
migration data, which vhost-user protocol features the backend for its
fs device supported. Instance 2 therefore never sent
GET_PROTOCOL_FEATURES to the second invocation of virtiofsd. This
should work, but it didn't, because update_reply_ack_flag() checked
whether self.protocol_features contained GET_PROTOCOL_FEATURES, but
self.protocol_features is only filled in when GET_PROTOCOL_FEATURES is
called. As a result, Cloud Hypervisor expected a reply that virtiofsd
would never send.
Since REPLY_ACK is handled entirely by the vhost-user library, and not
by the backend, there's no need to ask the backend whether it supports
REPLY_ACK in the first place, so we can just drop the check for that
from update_reply_ack_flag(). We know that we always support it, so
we just need to check whether the backend has acked it. This fixes
the hang described above.
Since we will now always reply if the backend acks the feature,
REPLY_ACK is now always included in the set of features returned by
GET_PROTOCOL_FEATURES, just like with XEN_MMAP (when enabled).
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Updates the requirements on [nix](https://github.com/nix-rust/nix) to permit the latest version.
Updates `nix` to 0.30.1
- [Changelog](https://github.com/nix-rust/nix/blob/master/CHANGELOG.md)
- [Commits](https://github.com/nix-rust/nix/compare/v0.29.0...v0.30.1)
---
updated-dependencies:
- dependency-name: nix
dependency-version: 0.30.1
dependency-type: direct:production
dependency-group: vhost
...
Signed-off-by: dependabot[bot] <support@github.com>
[SG] adapted the memfd_create call to comply with the new nix v0.30
interface
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
For use in QEMU, I would like GuestMemoryRegion to return a BitmapSlice
instead of a &Bitmap. This adds some flexibility that QEMU needs in
order to support a single global dirty bitmap that is sliced by the
various GuestMemoryRegions.
However, this removes access to the BitmapReplace trait, because it is of
course not possible to replace a slice of the bitmap only. Fortunately,
vhost is built around the GM<> type alias, which has a pluggable bitmap
type but hardcodes the backend:
type GM<B> = GuestMemoryAtomic<GuestMemoryMmap<B>>;
and therefore `region` is known to be a GuestRegionMmap. Adding a
single dereference of the GuestRegionMmap returns the MmapRegion to
which the bitmap is attached, thus calling MmapRegion::bitmap() instead
of <GuestRegionMmap as GuestRegion>::bitmap().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
New clippy version in the CI highlighted some code to improve.
This patch is generated using `clippy --fix ...`.
Fixed 2 type of warnings:
1 - error: the following explicit lifetimes could be elided: 'a
--> vhost-user-backend/src/bitmap.rs:109:6
|
109 | impl<'a> WithBitmapSlice<'a> for BitmapMmapRegion {
2 - error: unnecessary closure used to substitute value for `Option::None`
--> vhost-user-backend/src/handler.rs:356:21
|
356 | let vring = self
| _____________________^
357 | | .vrings
358 | | .get(index as usize)
359 | | .ok_or_else(|| VhostUserError::InvalidParam)?;
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Add support for the `VHOST_USER_GET_SHARED_OBJECT` request
in the backend. The GET_SHARED_OBJECT message is only usable
when VhostUserProtocolFeatures::SHARED_OBJECT feature is
negotiated. This support involves implementing a new method
`get_shared_object` to enable the frontend to retrieve a fd
from the backend about shared objects. When the frontend
sends this `GET_SHARED_OBJECT` message to the backend, the
backend opens a fd for use, and sends it's fd to the frontend.
The implementation of the `get_shared_object` method is
optional, and ensure that the function `get_shared_object`
returns an error if the backend does not implement it.
If the back-end supports shared objects, it should return
a `File` representing the fd.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Every time I do a release I notice this difference between
changelogs in this workspace, so let's try to uniform them by using
the form used in vhost-user-backend: without square brackets in the
title of the release and the `v` as prefix (v0.0.0).
Also fixed some difference in how we link PRs, let's follow the
most used way: [[#000]](url)
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
This release adds support for `VHOST_USER_RESET_DEVICE` and
updates vm-memory to 0.16.0 and virtio-queue to 0.13.0.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
This release adds support for `VHOST_USER_RESET_DEVICE` and
updates vm-memory to 0.16.0 and virtio-queue to 0.13.0.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
This version got yanked because the `gpu_socket` feature introduced
in this release was causing problems
(see [#265](https://github.com/rust-vmm/vhost/issues/265)).
Starting with the next version (v0.16.1), the `gpu_socket`
feature was removed.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Added mostly for being able to add a reasonable test to
vhost-user-backend/tests/vhost-user-server.rs.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Add an associated const to MockVhostBackend that reflects the feature
bits it supports, so we can easily verify this value in other places.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Handle RESET_DEVICE messages by disabling all vrings and resetting the
device state (but retaining the protocol state, i.e. the negotiated
protocol flags) as per the specification.
Just like all other protocol features, support for this is not
auto-announced, but back-end implementations must actively decide to do
so in their protocol_features() implementation.
Back-end implementation can define their own reset_device() handler to
reset additional device state, if necessary.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Remove the gpu-socket feature just introduced, since it doesn't work
well with cargo feature unification.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Remove the gpu-socket feature just introduced, since it doesn't work
well with cargo feature unification.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
relax the requirement of the trait when implementing
the `set_gpu_socket` method, make the `set_gpu_socket`
method optional, and ensure that the function `set_gpu_socket`
returns an error if the backend does not implement it.
Fixes#265
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Remove conditional compilation because when multiple crates
that are in thesame workspace set different features,
cargo feature unification already defeats the purpose of
the `gpu-socket` feature flag since cargo merges all the
feature flags specified by dependent crates into a single
set when compiling shared dependencies. for reference see:
[feature-unification](https://doc.rust-lang.org/cargo/reference/features.html#feature-unification)
Fixes: #265
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
By centralizing rust-vmm crates to workspace root, effectively reduce
places to look around when updating dependencies manually.
Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>
It can be useful to debug the various address mappings sent to a vhost
user device backend. impl Debug for both the postcopy and non-postcopy
versions of AddrMapping.
Signed-off-by: Tyler Fanelli <tfanelli@redhat.com>
This release has the following changes:
1. Move the set of event_idx property from set_vring_base callback to set_features one
2. Add shared objects support
3. Add support for `VHOST_USER_GPU_SET_SOCKET`
4. Update virtio-queue version from 0.12.0 to 0.13.0 and vm-memory from 0.14.0 to 0.15.0.
Signed-off-by: Muminul Islam <muislam@microsoft.com>
This release has the following changes:
1. Bump vm-memory crate from 0.14.0 to 0.15.0
2. Add shared objects support
3. Remove support for FS_* requests
4. Add support for `VHOST_USER_GPU_SET_SOCKET`
5. Ignore unknown bits in `VHOST_USER_GET_PROTOCOL_FEATURES` response.
Signed-off-by: Muminul Islam <muislam@microsoft.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>
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>
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>
