Commit Graph

24 Commits

Author SHA1 Message Date
Viresh Kumar
6d4eea1cf8 vsock: Set VhostUserProtocolFeatures::MQ
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>
2024-11-08 14:48:55 +05:30
Stefano Garzarella
e9819c001f Revert "vsock: Skip tests causing CI failure"
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>
2024-10-10 14:06:46 +05:30
Stefano Garzarella
ef98372646 chore: fix clippy warnings
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>
2024-09-25 10:27:44 +03:00
Dorjoy Chowdhury
cec57c9433 vsock: Skip tests causing CI failure
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>
2024-09-05 12:09:50 +02:00
Dorjoy Chowdhury
8646373e96 vsock: Support for vsock backend
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>
2024-09-05 12:09:50 +02:00
Dorjoy Chowdhury
1e670ff1b5 vsock: Introduce enum types for UDS backend
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>
2024-09-05 12:09:50 +02:00
Dorinda Bassey
d6a10d7565 vsock: Replace the config Crate with figment
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>
2024-07-22 12:50:46 +02:00
Dorinda Bassey
b7f15e31e7 vsock: rename variable for clarity
in order to improve code readability, rename variable
to be more descriptive

Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
2024-07-22 12:50:46 +02:00
Dorjoy Chowdhury
f7724bf8ec vhost-device-vsock: change default vring queue size to 1024
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>
2024-07-10 17:14:18 +03:00
Dorjoy Chowdhury
9d34131945 vhost-device-vsock: introduce queue-size option
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>
2024-07-10 17:14:18 +03:00
Ramyak Mehra
db6de9960d vsock: exit early while reading connect message from socket
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>
2024-06-07 10:46:09 +05:30
Stefano Garzarella
65140bff6a Use Vec::first() instead of Vec::get(0)
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>
2024-01-15 13:13:37 +02:00
Viresh Kumar
00ad80d736 vhost-device: Don't return bool unnecessarily
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>
2023-12-01 09:40:52 +01:00
Erik Schilling
2143bcb44c tree-wide: continue unwinds on join failures
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>
2023-11-20 13:05:48 +05:30
Erik Schilling
25c6ac3362 tree-wide: use new serve convenience function
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>
2023-11-20 13:05:48 +05:30
Erik Schilling
31154ea0da Update vhost-user-backend to 0.11 series
- 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>
2023-11-14 10:48:19 +02:00
Erik Schilling
1556756314 vsock: fix read/write impls of mock object
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>
2023-11-14 10:48:19 +02:00
Stefano Garzarella
fdf3c30e08 vsock/test: fix intermittent failures
`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>
2023-11-09 11:45:26 +02:00
Stefano Garzarella
5847489855 vsock: increase test coverage
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>
2023-11-08 12:34:12 +02:00
Stefano Garzarella
197dac1c81 vsock: exit if some threads terminate with errors/panics
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>
2023-11-08 12:34:12 +02:00
Jeongik Cha
6d0f7f64e5 vsock: adding log for epoll_register error in send_pkt
like recv_pkt, added log for epoll_register error instead of panic
Signed-off-by: Jeongik Cha <jeongik@google.com>
2023-10-31 13:52:01 +05:30
Jeongik Cha
4b6451176d vsock: try epoll_modify before epoll_register in recv_pkt
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>
2023-10-31 13:52:01 +05:30
Stefano Garzarella
09e9da304c vsock: avoid circular references
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>
2023-10-27 16:13:37 +05:30
Manos Pitsidianakis
a1e013286f Move all crates to workspace root
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>
2023-10-16 12:03:57 +05:30