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>
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>
Let's add the `VHOST_USER_PROTOCOL_F_DEVICE_STATE` feature flag, and
handling the messages to support tha backend internal state migration.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: German Maglione <gmaglione@redhat.com>
If `VHOST_USER_PROTOCOL_F_DEVICE_STATE` has been negotiated, these
methods will be called on receiving the `SET_DEVICE_STATE_FD` and
`CHECK_DEVICE_STATE` messages.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: German Maglione <gmaglione@redhat.com>
This was introduced in 7f326dd314, but
doesn't work with qemu versions < 7.2. SET_FEATURES is received before
SET_VRING_KICK, we will enable the vrings in set_features() and disabled
them later in set_vring_kick().
Currently, the libvhostuser in qemu disables the vring upon receiving
RESET_OWNER, but that message is currently deprecated. There is not a
sane place to disable the vring, since according to the spec we can only
do that upon receiving RESET_OWNER (deprecated), RESET_DEVICE (currently
not supported in this crate), and SET_VRING_ENABLE.
The current state of the vhost-user spec is a mess, we need a more
formal spec that just a wall of english.
Signed-off-by: German Maglione <gmaglione@redhat.com>
According to the vhost-user spec (as the code shows) the vring status
must not be modified if `VHOST_USER_F_PROTOCOL_FEATURES` has been
negotiated.
Signed-off-by: German Maglione <gmaglione@redhat.com>
Before this release, vhost-user devices using this crate were
limited to 32 memslots. This does not support well the integration
with virtio-mem.
For more details: https://issues.redhat.com/browse/RHEL-15317
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Let's support up to 509 mem slots, just like vhost in the kernel usually
does. This is required to properly support memory hotplug, either using
multiple DIMMs (ACPI supports up to 256) or using virtio-mem.
The 509 used to be the KVM limit, it supported 512, but 3 were
used for internal purposes. Currently, KVM supports more than 512, but
it usually doesn't make use of more than ~260 (i.e., 256 DIMMs + boot
memory), except when other memory devices like PCI devices with BARs are
used. So, 509 seems to work well for vhost in the kernel.
Details can be found in the QEMU change that made virtio-mem consume
up to 256 mem slots across all virtio-mem devices. [1]
509 mem slots implies 509 VMAs/mappings in the worst case (even though,
in practice with virtio-mem we won't be seeing more than ~260 in most
setups).
With max_map_count under Linux defaulting to 64k, 509 mem slots
still correspond to less than 1% of the maximum number of mappings.
There are plenty left for the application to consume.
[1] https://lore.kernel.org/all/20230926185738.277351-1-david@redhat.com/
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: German Maglione <gmaglione@redhat.com>
This release only includes a dependency update, which is visible in the
public API through `VhostBackend::set_vring_kick` and
`VhostBackend::set_vring_call`.
Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
The update brings a fix for a security vulnerability behind
feature-gated code not used by vhost (the `with-serde` feature),
see GHSA-875g-mfp6-g7f9
Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
In many places we access the `VhostUserHandler::vrings` array many
times and at the beginning of each function we check the index to
avoid OOB.
It happened that we forgot about this check (see #211), so let's
avoid this error-prone pattern by taking the reference to the vring
using `Vec::get()`, and avoiding multiple indexing.
Suggested-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
VHostUserHandler::set_vring_base() lacks validation of the input
parameter `index`, which is used for indexing an internal vector and
could potentially lead to a Out-of-Bounds write resulting in a panic.
Closes#211
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Having all the workspace crates under the crates/ directory is
unnecessary. Rust documentation itself recommends all crates to be in
the root directory:
https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html#creating-the-second-package-in-the-workspace
I paste the text content here, in case the online page ever changes or
becomes unavailable:
## Creating the Second Package in the Workspace
Next, let’s create another member package in the workspace and call it add_one. Change the top-level Cargo.toml to specify the add_one path in the members list:
Filename: Cargo.toml
[workspace]
members = [
"adder",
"add_one",
]
Then generate a new library crate named add_one:
$ cargo new add_one --lib
Created library `add_one` package
Your add directory should now have these directories and files:
├── Cargo.lock
├── Cargo.toml
├── add_one
│ ├── Cargo.toml
│ └── src
│ └── lib.rs
├── adder
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── target
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
