Cross-check the packet `src_cid` with the CID configured for the guest.
This will forbid a VM from impersonating another.
Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Adds support for communication between sibling VMs that use the
vhost-user-vsock devices from the same vhost-user-vsock application.
Tested with nc-vsock patched to set `.svm_flags = VMADDR_FLAG_TO_HOST`:
host$ vhost-user-vsock \
--vm guest-cid=3,uds-path=/tmp/vm3.vsock,socket=/tmp/vhost3.socket \
--vm guest-cid=4,uds-path=/tmp/vm4.vsock,socket=/tmp/vhost4.socket
vm_cid3$ nc-vsock -l 1234
vm_cid4$ nc-vsock 3 1234
Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
In future, we could add the ability to change the configuration at runtime
and allow new guests to be added even without having to restart the
daemon. So it is reasonable to not differentiate between the single and
multiple VM cases, even with only one guest.
Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
This simplifies the packaging and allows using existing tooling to
manage further updates.
The lock file was updated with:
cargo update -p libgpiod --aggressive
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Adds support for instantiating multiple `VhostUserVsockBackend`s parallely
to handle multiple guests. Extends the CLI interface to accept the config
for multiple VMs in addition to the yaml config file with the `--vm`
argument as follows:
vhost-user-vsock \
--vm guest_cid=3,socket=/tmp/vhost3.socket,uds_path=/tmp/vm3.vsock \
--vm guest_cid=4,socket=/tmp/vhost4.socket,uds_path=/tmp/vm4.vsock
Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Polishing this up for inclusion is currently not high on the priority
list, but we can at least link it.
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
This provides some tooling for running blktests. The README.md contains
documentation about the architecture.
I am seeing some race-conditions that sometimes lead to boot
freezes [1], so this is not really ready for automatic evaluation during
a CI pipeline.
[1] https://linaro.atlassian.net/browse/ORKO-37
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Link: https://linaro.atlassian.net/browse/ORKO-17
While the command also allows syncing individual regions of a LUN, we
do not support that here and simply sync the entire file.
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
WRITE SAME allows writing a block for a repeated number of times.
Mostly, it can also be used to deallocate parts of the block device
(the fstrim functionality uses this). We do not support that aspect
yet. Instead, we will just stupidly repeat the pattern as many times
as we are told.
A future, smarter implementation could just punch a hole into the
backend instead of filling it with zeros.
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
This adds write support. Being very similar to READ(10) in structure,
much of the code is very similar.
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
The config that we send is based on the current QEMU defaults
(as of 60ca584b8af0de525656f959991a440f8c191f12).
This allows testing using Alex Bennee's vhost-user-generic series and
will be required for hypervisors that do not come with the stubs that
QEMU has (eg: Xen).
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Link: https://lore.kernel.org/all/20230414160433.2096866-1-alex.bennee@linaro.org/
This adds the virtio-specific parts that use the previously formed
interfaces and scsi emulation in order to build a daemon that offers files
from the host system as drives to the guest.
The vast majority of this work was done by Gaelan Steele as part of a
GSoC project [1][2].
[1] https://github.com/rust-vmm/vhost-device/pull/4
[2] https://gist.github.com/Gaelan/febec4e4606e1320026a0924c3bf74d0
Co-developed-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Gaelan Steele <gbs@canishe.com>
This implements the previously defined interface by emulating the commands
against a file-backed block device.
The vast majority of this work was done by Gaelan Steele as part of a
GSoC project [1][2].
[1] https://github.com/rust-vmm/vhost-device/pull/4
[2] https://gist.github.com/Gaelan/febec4e4606e1320026a0924c3bf74d0
Co-developed-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Gaelan Steele <gbs@canishe.com>
This defines the basic interface that any scsi device will have to
implement (along with some sensing constants that may be useful to share).
The vast majority of this work was done by Gaelan Steele as part of a
GSoC project [1][2].
[1] https://github.com/rust-vmm/vhost-device/pull/4
[2] https://gist.github.com/Gaelan/febec4e4606e1320026a0924c3bf74d0
Co-developed-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Gaelan Steele <gbs@canishe.com>
It's possible to receive an incoming UDS connection before the VMM has
contacted us to initialize the vrings.
In this case, close the incoming connection so the client is aware of we
aren't yet ready, and to avoid having a lingering incomplete connection
around.
Signed-off-by: Sergio Lopez <slp@redhat.com>
It's possible to receive backend events before the VMM contacts us to
activate the vrings. Trying to call process_tx in this state will
trigger a NoMemoryConfigured error which will end crashing the worker
thread.
As NoMemoryConfigured is a transitory error, deal with it gracefully
printing a warning but continuing the normal execution.
Signed-off-by: Sergio Lopez <slp@redhat.com>
