From 051fc0d5e4bafd578f5adf88e2db284e78b6b870 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Wed, 5 Jan 2022 13:00:42 +0530 Subject: updates Signed-off-by: Viresh Kumar --- rust/.gpio.txt.swp | Bin 36864 -> 36864 bytes rust/gpio.html | 98 +++++++++++++++++++++++++++++++++++++++++++++++----- rust/gpio.txt | 99 ++++++++++++++++++++++++++++++++++++++++++++++++----- 3 files changed, 181 insertions(+), 16 deletions(-) diff --git a/rust/.gpio.txt.swp b/rust/.gpio.txt.swp index 5523aa2..ec6da3d 100644 Binary files a/rust/.gpio.txt.swp and b/rust/.gpio.txt.swp differ diff --git a/rust/gpio.html b/rust/gpio.html index 76158e0..9012aa4 100644 --- a/rust/gpio.html +++ b/rust/gpio.html @@ -13,7 +13,7 @@

There is a growing trend towards virtualization in areas other than the traditional server environment. The server environment is uniform in nature, but as we move towards a richer ecosystem in automotive, medical, general mobile and -the IoT spaces, more device abstractions and way richer organizations are +the IoT spaces, more device abstractions, and way richer organizations are needed. Linaro’s Project Stratos is working towards developing hypervisor agnostic abstract devices leveraging virtio and extending hypervisor interfaces and standards to allow all @@ -42,9 +42,9 @@ independent of where the virtqueue processing happens at the host, in-kernel or userspace. The vhost protocol allows the virtio virtqueue processing at the host to be offloaded to another element, a user process or a kernel module. The vhost protocol when implemented in userspace is called as "vhost-user". Since -Linaro’s Project Stratos is targeting hypervisor agnostic BE drivers, we decided -to work over the existing vhost-user protocol. This article focuses on the Rust -based vhost-user implementation for I2C devices.

+Linaro’s Project Stratos is targeting hypervisor agnostic BE drivers, engineers +at Linaro decided to work over the existing vhost-user protocol. This article +focuses on the Rust based vhost-user implementation for I2C devices.

Virtio I2C Specification

The Virtio @@ -109,7 +109,7 @@ host BE driver to notify the guest with the status of the transfer with specification of more details.

-

Rust I2C backend (BE)

+

Rust based I2C backend

Rust is the next big thing disrupting the Linux world and most of us are already aware of the Rust for Linux project slowly making its way into the Linux kernel. Rust is a multi-paradigm, @@ -133,15 +133,97 @@ and Intel’s . The rust-vmm project currently roughly 30 repositories (or Rust crates, equivalent of a C library), where each crate plays a special role in the development of a fully functioning VMM.

-

One such component is the +

One such component provided by the rust-vmm project is the vhost-user-backend crate, which has recently made its way to crates.io, the Rust -community’s crate registry. The vhost-user-backend crate provides a framework to implement the vhost-user backend services

+community’s crate registry. The vhost-user-backend crate provides a framework to +implement the vhost-user backend services. It provides necessary public APIs to +support vhost-user backends, like a daemon control object (VhostUserDaemon) to +start and stop the service daemon, a vhost-user backend trait +(VhostUserBackendMut) to handle vhost-user control messages and virtio +messages, and a vring access trait (VringT) to access virtio queues.

+

A separate Rust workspace, +vhost-device, is recently created +in the rust-vmm project, to host per-device vhost-user backend crates. The only +crate merged there as for now is for the I2C device, while there are others +getting developed and reviewed as we speak, like GPIO, RNG, VSOCK, SCSI, and +RPMB.

+

The I2C vhost-device binary-crate (generates an executable upon build), +developed by Viresh Kumar (Linaro), supports sharing host I2C busses (Adaptors) +and client devices with multiple guest VMs at the same time with a single +instance of an always running backend daemon. Once the vhost-device crate is +compiled with cargo build --release, it generates the +target/release/vhost-device-i2c executable. The vhost-device-i2c daemon +communicates with guest VMs over Unix domain sockets, a unique socket for each +VM.

+

The daemon accepts three arguments:

+ +

As an example, consider the following command:

+
+
./vhost-device-i2c -s ~/i2c.sock -c 6 -l 6:32:41,9:37:6
+
+

This will start the I2C backend daemon, which will create 6 Unix domain sockets +(/i2c.sock0, .., /i2c.sock5), in order to communicate with 6 guest VMs, where +communication with each VM happens in parallel with the help of a separate +native OS thread. Once the threads are created by the daemon, the threads wait +for a VM to start communicating on the thread’s designated socket. Later, when a +VM shuts down, the respective thread starts waiting for a new VM to communicate +on the same socket path. The daemon is also passed a list of host I2C busses and +client devices, which are shared by all the VMs. The daemon can be modified +later on, if required, to allow specific devices to be accessed only by a +particular VM, this feature isn’t added in the current version of the daemon. In +the above example, the devices shared by the host with the daemon are: devices +with address 32 and 41 attached to I2C bus 6, 37 and 6 attached to I2C bus 9. +The daemon extensively validates the device-list at initialization to avoid any +failures later.

+

The vhost-user-i2c daemon supports both I2C and SMBus protocols, only basic +SMBus commands up to word-transfer. The backend provides the pub trait +I2cDevice, a public Rust trait, which can be implemented for different host +environments to provide access to the underlying I2C busses and devices. This is +currently implemented only for the Linux userspace, where the I2C busses and +devices are accessed via the /dev/i2c-X I2C device files. For the above +example, the backend daemon will look for /dev/i2c-6 and /dev/i2c-9 device +files. The users may need to load the i2c-dev kernel module, if not loaded +already, for these device files to be available under /dev/. For a different +host environment, like a bare-metal type 1 hypervisor, we need to add another +implementation of the trait depending on how the I2C busses and devices are +accessed.

+

The vhost-user-i2c backend is truly a hypervisor agnostic solution that works +with any hypervisor which understands the vhost-user protocol. It has been +extensively tested with QEMU for example, with Linux userspace environment. Work +is in progress to make Xen hypervisor vhost-user protocol compatible. Once that +is done, we will be able to use the same vhost-user-i2c executable with both +QEMU and Xen, for example, under the same host environments.

+

Support for virtio-i2c is already merged in QEMU source, boilerplate stuff to +create the virtio-i2c device in the guest kernel, and the virtio-i2c device can +be created in the guest kernel by adding following command line arguments to +your QEMU command:

+

-chardev socket,path=~/i2c.sock0,id=vi2c -device vhost-user-i2c-device,chardev=vi2c,id=i2c

Last updated - 2022-01-04 12:48:12 IST + 2022-01-05 12:58:45 IST

diff --git a/rust/gpio.txt b/rust/gpio.txt index 2b128dd..6148e6b 100644 --- a/rust/gpio.txt +++ b/rust/gpio.txt @@ -4,7 +4,7 @@ Rust based vhost-user I2C backend There is a growing trend towards virtualization in areas other than the traditional server environment. The server environment is uniform in nature, but as we move towards a richer ecosystem in automotive, medical, general mobile and -the IoT spaces, more device abstractions and way richer organizations are +the IoT spaces, more device abstractions, and way richer organizations are needed. link:https://www.linaro.org/projects/#automotive_STR[Linaro's Project Stratos] is working towards developing hypervisor agnostic abstract devices leveraging virtio and extending hypervisor interfaces and standards to allow all @@ -36,9 +36,9 @@ independent of where the virtqueue processing happens at the host, in-kernel or userspace. The vhost protocol allows the virtio virtqueue processing at the host to be offloaded to another element, a user process or a kernel module. The vhost protocol when implemented in userspace is called as "vhost-user". Since -Linaro's Project Stratos is targeting hypervisor agnostic BE drivers, we decided -to work over the existing vhost-user protocol. This article focuses on the Rust -based vhost-user implementation for I2C devices. +Linaro's Project Stratos is targeting hypervisor agnostic BE drivers, engineers +at Linaro decided to work over the existing vhost-user protocol. This article +focuses on the Rust based vhost-user implementation for I2C devices. Virtio I2C Specification ------------------------ @@ -114,8 +114,8 @@ Please refer the Virtio I2C link:https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex[specification] of more details. -Rust I2C backend (BE) ---------------------- +Rust based I2C backend +---------------------- Rust is the next big thing disrupting the Linux world and most of us are already aware of the link:https://github.com/Rust-for-Linux[Rust for Linux] project @@ -142,7 +142,90 @@ Hypervisor]. The rust-vmm project currently roughly 30 repositories (or Rust crates, equivalent of a C library), where each crate plays a special role in the development of a fully functioning VMM. -One such component is the +One such component provided by the rust-vmm project is the link:https://crates.io/crates/vhost-user-backend[vhost-user-backend] crate, which has recently made its way to link:https://crates.io/[crates.io], the Rust -community’s crate registry. The vhost-user-backend crate provides a framework to implement the vhost-user backend services +community’s crate registry. The vhost-user-backend crate provides a framework to +implement the vhost-user backend services. It provides necessary public APIs to +support vhost-user backends, like a daemon control object (`VhostUserDaemon`) to +start and stop the service daemon, a vhost-user backend trait +(`VhostUserBackendMut`) to handle vhost-user control messages and virtio +messages, and a vring access trait (`VringT`) to access virtio queues. + +A separate Rust workspace, +link:https://github.com/rust-vmm/vhost-device[vhost-device], is recently created +in the rust-vmm project, to host per-device vhost-user backend crates. The only +crate merged there as for now is for the I2C device, while there are others +getting developed and reviewed as we speak, like GPIO, RNG, VSOCK, SCSI, and +link:https://en.wikipedia.org/wiki/Replay_Protected_Memory_Block[RPMB]. + +The I2C vhost-device binary-crate (generates an executable upon build), +developed by Viresh Kumar (Linaro), supports sharing host I2C busses (Adaptors) +and client devices with multiple guest VMs at the same time with a single +instance of an always running backend daemon. Once the vhost-device crate is +compiled with `cargo build --release`, it generates the +`target/release/vhost-device-i2c` executable. The `vhost-device-i2c` daemon +communicates with guest VMs over Unix domain sockets, a unique socket for each +VM. + +The daemon accepts three arguments: + +* -s, --socket-path: Path of the vhost-user Unix domain sockets. This is + suffixed with 0,1,2..socket_count-1 by the daemon to obtain actual socket + paths. + +* -c, --socket-count: Number of sockets (guests) to connect to. This parameter + is optional and defaults to 1. + +* -l, --device-list: List of I2C bus and clients in the format + :[:][,:[:]] + +As an example, consider the following command: + +---- +./vhost-device-i2c -s ~/i2c.sock -c 6 -l 6:32:41,9:37:6 +---- + +This will start the I2C backend daemon, which will create 6 Unix domain sockets +(~/i2c.sock0, .., ~/i2c.sock5), in order to communicate with 6 guest VMs, where +communication with each VM happens in parallel with the help of a separate +native OS thread. Once the threads are created by the daemon, the threads wait +for a VM to start communicating on the thread's designated socket. Later, when a +VM shuts down, the respective thread starts waiting for a new VM to communicate +on the same socket path. The daemon is also passed a list of host I2C busses and +client devices, which are shared by all the VMs. The daemon can be modified +later on, if required, to allow specific devices to be accessed only by a +particular VM, this feature isn't added in the current version of the daemon. In +the above example, the devices shared by the host with the daemon are: devices +with address 32 and 41 attached to I2C bus 6, 37 and 6 attached to I2C bus 9. +The daemon extensively validates the device-list at initialization to avoid any +failures later. + +The `vhost-user-i2c` daemon supports both I2C and SMBus protocols, only basic +SMBus commands up to word-transfer. The backend provides the `pub trait +I2cDevice`, a public Rust trait, which can be implemented for different host +environments to provide access to the underlying I2C busses and devices. This is +currently implemented only for the Linux userspace, where the I2C busses and +devices are accessed via the `/dev/i2c-X` I2C device files. For the above +example, the backend daemon will look for `/dev/i2c-6` and `/dev/i2c-9` device +files. The users may need to load the `i2c-dev` kernel module, if not loaded +already, for these device files to be available under `/dev/`. For a different +host environment, like a bare-metal type 1 hypervisor, we need to add another +implementation of the trait depending on how the I2C busses and devices are +accessed. + +The `vhost-user-i2c` backend is truly a hypervisor agnostic solution that works +with any hypervisor which understands the vhost-user protocol. It has been +extensively tested with QEMU for example, with Linux userspace environment. Work +is in progress to make Xen hypervisor vhost-user protocol compatible. Once that +is done, we will be able to use the same `vhost-user-i2c` executable with both +QEMU and Xen, for example, under the same host environments. + +Support for virtio-i2c is already merged in QEMU source, boilerplate stuff to +create the virtio-i2c device in the guest kernel, and the virtio-i2c device can +be created in the guest kernel by adding following command line arguments to +your QEMU command: + +---- +`-chardev socket,path=~/i2c.sock0,id=vi2c -device vhost-user-i2c-device,chardev=vi2c,id=i2c` +---- -- cgit v1.2.3