These where most likely missed during a re-factor to use PathBuf.
Fixes: 0b6314f (vsock: Use PathBuf for socket paths instead of Strings)
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
dbg! does not use format specifiers and prints in stderr regardless of
log output. Use log::debug! instead.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
virtio-queue v0.15 introduces a new Descriptor API supporting both
split and packed virtqueue.
Update our dependencies and code to work with the new version
of the crate, including updating vhost-user-backend and virtio-vsock.
Updates `vhost-user-backend` from 0.18.0 to 0.19.0
- [Release notes](https://github.com/rust-vmm/vhost/releases)
- [Commits](rust-vmm/vhost@vhost-user-backend-v0.18.0...vhost-user-backend-v0.19.0)
Updates `virtio-queue` from 0.14.0 to 0.15.0
- [Release notes](https://github.com/rust-vmm/vm-virtio/releases)
- [Commits](rust-vmm/vm-virtio@virtio-queue-v0.14.0...virtio-queue-v0.15.0)
Updates `virtio-vsock` from 0.8.0 to 0.9.0
- [Release notes](https://github.com/rust-vmm/vm-virtio/releases)
- [Commits](rust-vmm/vm-virtio@virtio-vsock-v0.8.0...virtio-vsock-v0.9.0)
Signed-off-by: Wenyu Huang <huangwenyuu@outlook.com>
Data from the tx queue was being handled incorrectly when it only
partially fit at the end of the circular buffer: The beginning of the
data was being copied again to start of the circular buffer.
Signed-off-by: Jorge E. Moreira <jemoreira@google.com>
Currently the vsock connection always triggers on EPOLLOUT. When a host
applicationlistens to the UDS, it's almost always writable, and thus
keeps triggering backend events with EPOLLOUT on the connection. As a
result, vhost-device-vsock daemon consumes 100% CPU.
To make it more CPU efficient, it can instead unsubscribe EPOLLOUT
whenever there is no more data to send. It can re-subscribe if the
connection cannot write out all bytes. This change causes the CPU util
to drop to negligible level.
Signed-off-by: Leon Yang <lnyng@meta.com>
Fix new warn by default clippy lint, empty_line_after_doc_comments,
by removing empty lines after doc comments.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
test_vsock_thread_backend_vsock() and test_vsock_thread_vsock_backend()
tests use VMADDR_CID_LOCAL which is provided by the `vsock_loopback`
kernel module.
If `vsock_loopback` kernel module is not loaded, these tests will fail
later with unclear messages, so it can be hard to debug.
Let's fail early and print a message with the requirement.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Instead of using the direct value (1), let's use the constant value
provided by the vsock crate.
VMADDR_CID_LOCAL is used for loopback communication, which is used
in some of our test cases.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
As per the vhost-user specification:
"Back-ends should always implement the VHOST_USER_PROTOCOL_F_MQ protocol
feature, even for devices with a fixed number of virtqueues, since it is
simple to implement and offers a degree of introspection."
Vsock backend support three virtqueues and hence this should be set.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
This reverts commit cec57c9433.
Now our CI is able to use AF_VSOCK, so let's force the tests
to run to discover any problems in the future.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
The new version of clippy in the CI suggested several improvements.
Some fixed with `clippy --fix`, some by hand.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Some new tests added in the previous commit fail in CI due to missing
support for AF_VSOCK. The tests are now skipped when we detect that
AF_VSOCK is not available.
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
This commit adds support for proxying the communication with a VM
using vsock, similar to already existing support using unix domain
socket through the uds-path option. Two new options have been
introduced:
- forward-cid
- forward-listen
The forward-cid option (u32) allows users to specify the CID to which
all the connections from the VM should be forwarded to, regardless of
the target CID of those connections. Users would typically forward to
CID 1 i.e., the host machine.
The forward-listen option (string) is a list of ports separated by '+'
for forwarding connections from the host machine to the VM.
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Right now, vhost-device-vsock supports only unix domain socket as
backend. The following commit will add support for vsock backend.
This is a preparation commit wrapping the unix domain socket related
stuff in enum types so that the following commit can extend on that
for vsock backend support.
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
The config crate, which was previously used in vsock is no longer
maintained. To ensure continued support and improvement, the
figment crate is used as a replacement for configuration management.
Closes#639
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Although increasing queue size from 256 to 1024 increases the memory
usage of vhost-device-vsock, 1024 is a reasonable default which should
make vhost-device-vsock work by default (i.e., without using the
queue-size option) with devices that use vring queue size up to 1024
such as QEMU's vhost-user-vsock-device.
If Users require greater or smaller queue size, they can use the
'queue-size' option to configure the queue size.
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
The vring queue size was hardcoded to 256 which is problematic for
vsock devices that use a larger queue size. For example, when using
vhost-device-vsock with QEMU's vhost-user-vsock-device, the message
to set the vring queue size to 1024 causes an "InvalidParameter"
error from vhost-device-vsock. Making the queue size configurable
via an option makes it easy to use vhost-device-vsock where a larger
queue size is required.
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Before this change, we read a fixed number of bytes before checking `\n`.
If the user provided less than that, the application would wait indefinitely.
Let`s remove this limitation by using buffered reading and checking `\n`
from the beginning of the input.
Fixes: #307
Signed-off-by: Ramyak Mehra <ramyak@dyte.io>
Fix the following clippy warning:
warning: accessing first element with `configs.get(0)`
--> vhost-device-vsock/src/main.rs:410:22
|
410 | let config = configs.get(0).unwrap();
| ^^^^^^^^^^^^^^ help: try: `configs.first()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#get_first
= note: `#[warn(clippy::get_first)]` on by default
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Since everyone copied the first bits of code from the I2C crate, the
same issue is present almost everywhere. The returned value isn't
checked at all by the callers. Stop returning bool unnecessarily.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The error from joining a thread is a bit confusing. It is only printed
if the other thread panicked. This means, effectively, we only get here
if something called .unwrap(), .expect() or panicked in a different way.
In these cases an (ugly) error was already printend. Printing a pretty
message about the join failure does not really help a lot...
So let's just continue the unwind as suggested by the docs on the join
`Result` [1].
Before:
thread '<unnamed>' panicked at 'Test panic', crates/gpio/src/backend.rs:146:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', crates/gpio/src/backend.rs:176:23
After:
thread '<unnamed>' panicked at 'Test panic', crates/gpio/src/backend.rs:146:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[1]: https://doc.rust-lang.org/std/thread/type.Result.html
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
This become available with the recent vhost-user-backend [1] updates and
allows to get rid of some boilerplate code.
[1] https://github.com/rust-vmm/vhost/pull/173
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
- Features were renamed from slave -> backend
- Generics got simplified
- Some write and read functions on Volatile slice got turned into
standalone traits: ReadVolatile, WriteVolatile
- handle_event no longer returns a bool
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
These Read/Write implementations always read/wrote to the start of the
slice. This is a bit awkward and does not become easier by the test
relying on this behaviour.
Fix this by using a pair of VecDequeue, one for the read and one for the
write buffer. This better mimics a pair of network sockets. This allows
mocking the read/writes in a bit more natural ways.
VecDeque also implements Read/Write, making our impls for those a simple
forward.
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
`test_start_backend_servers_failure` is failing intermittently.
In slow systems it can happen that one thread is exiting due to
an error (in this case we expect a CidAlreadyInUse error) and
another thread is creating files (Unix socket), so sometimes
test_dir.close() fails because after deleting all the files it
finds more. So let's discard eventual errors.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Add more tests in vhost-device-vsock to increase the coverage.
Some of them are really simple and perhaps nonsensical (tests for
Debug, Clone, etc.), but for now we don't know how to disable this
in the tool, so let's cover these cases.
The vhost-device-vsock functions coverage increases from 70.73% to
90.45%:
Filename Functions Missed Functions Executed
----------------------------------------------------------
main.rs 51 12 76.47%
rxops.rs 8 0 100.00%
rxqueue.rs 20 0 100.00%
thread_backend.rs 20 3 85.00%
txbuf.rs 17 0 100.00%
vhu_vsock.rs 37 1 97.30%
vhu_vsock_thread.rs 40 5 87.50%
vsock_conn.rs 27 0 100.00%
----------------------------------------------------------
TOTAL 220 21 90.45%
Closes#229
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Now that we support multiple VMs, we launch a thread for each
VM during startup.
If one of the threads other than the first one terminates with an
error or panic, the main thread waits for the first one in the join().
For example, if we launch two VMs with the same CID, if the first
thead starts after the second one, we see the error printed and
exit, otherwise we see nothing and the main stays waiting for the
first thread.
So let's introduce a channel where the various threads can notify main
and use `std::panic::catch_unwind()` to do so even if a panic happens.
If one of the threads terminates with an error or panic, we exit
immediately.
Add also a test to check this case
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
in this context, epoll listener can be already registered via other TX
event, so let it try epoll_modify first to avoid 'silent' failure which
possibly drops packets.
Signed-off-by: Jeongik Cha <jeongik@google.com>
We have the following circular references found by Li Zebin:
VhostUserBackend ==> VhostUserVsockThread ==> VringEpollHandler
In addition to causing a resource leak, this causes also an error
after we merged commit 38caab2 ("vsock: Don't allow duplicate CIDs").
When the VM reboot or shutdown, the application exits with the
following error:
[ERROR vhost_device_vsock] Could not create backend:
CID already in use by another vsock device
This happened because we have these circular references and
VhostUserVsockThread::drop() is never invoked. So, we don't remove
the cid from the map.
Let's fix this problem by simply removing the reference to
VringEpollHandler from VhostUserVsockThread. In fact, we do not
need to keep the reference for the lifetime of VhostUserVsockThread,
as we only need to add the handlers once.
Let's also rename the fields to follow the current VhostUserDaemon
API.
Closes#438
Reported-by: Li Zebin <cutelizebin@gmail.com>
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>
