From c8208ea70f8804d6c4eb4b1aef9c90f24ea3d5be Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Tue, 4 Jan 2022 13:02:15 +0530 Subject: updates Signed-off-by: Viresh Kumar --- rust/gpio.html | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 rust/gpio.html (limited to 'rust/gpio.html') diff --git a/rust/gpio.html b/rust/gpio.html new file mode 100644 index 0000000..76158e0 --- /dev/null +++ b/rust/gpio.html @@ -0,0 +1,147 @@ + + + + + +Rust based vhost-user I2C backend + + +

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 +needed. Linaro’s Project +Stratos is working towards developing hypervisor agnostic abstract devices +leveraging virtio and extending hypervisor interfaces and standards to allow all +architectures.

The Virtual Input/Output device (Virtio) standard provides an open interface for +guest virtual machines (VMs) to access simplified "virtual" devices, such as +network adapters and block devices, in a paravirtualized environment. Virtio +provides a straightforward, efficient, standard and extensible mechanism for +virtual devices, rather than a per-environment or per-OS mechanism.

The backend (BE) virtio driver, implemented in the hypervisor running on the host, +exposes the virtio device to the guest OS through a transport method, like PCI +or MMIO. The virtio device, by design, looks like a physical device to the guest +OS, which implements a frontend (FE) virtio driver compatible with the virtio +device exposed by the hypervisor. The virtio device and driver communicate based +on a set of predefined protocols as defined by the +virtio specification, which is +maintained by OASIS. The FE driver can +implement zero or more Virtual queues (virtqueues), as defined by the virtio +specification. The virtqueues are the mechanism of bulk data transport between +FE (guest) and BE (host) drivers. These are normally implemented as standard +ring buffers in the guest physical memory by the FE drivers. The BE drivers +parse the virtqueues to obtain the request descriptors, process them and queue +the response descriptors back to the virtqueue.

The FE virtio driver at the guest and the virtio specification are normally +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.

Virtio I2C Specification

The Virtio +specification +for I2C and the Linux +i2c-virtio +driver are upstreamed by Jie Deng (Intel), who tested his work with the +ACRN hypervisor for IoT development. Both +specification and driver received updates later on by Viresh Kumar (Linaro), to +improve buffer management and allow zero-length transactions. Lets go through +the I2C virtio specification briefly.

virtio-i2c is a virtual I2C adapter device, which provides a way to flexibly +organize and use the host I2C controlled devices from the guest. All +communication between the FE and BE drivers happens over the "requestq" +virtqueue. It is also mandatory for both the sides to implement the +VIRTIO_I2C_F_ZERO_LENGTH_REQUEST feature, which allows zero-length transfers +(like SMBus Quick) to take place. The I2C requests always originate at the guest +FE driver, where the FE driver puts one or more I2C requests, represented by the +struct virtio_i2c_req, on the requestq virtqueue. The I2C requests may or may +not be be interdependent. If multiple requests are received together, then the +host BE driver must process the requests in the order they are received on the +virtqueue.

struct virtio_i2c_req {
+        struct virtio_i2c_out_hdr out_hdr;
+        u8 buf[];
+        struct virtio_i2c_in_hdr in_hdr;
+};

Each I2C virtio request consists of an out_hdr (set by the FE driver), followed by +an optional buffer of some length (set by FE or BE driver based on if the +transaction is write or read), followed by an in_hdr (set by the BE driver). The +buffer is not sent for zero-length requests, like for the SMBus Quick command +where no data is required to be sent or received.

struct virtio_i2c_out_hdr {
+        le16 addr;
+        le16 padding;
+        le32 flags;
+};

The out_hdr is represented by the struct virtio_i2c_out_hdr. The addr +field of the header is the address of the I2C controlled device. Both 7-bit and +10-bit address modes are supported by the specification (though only 7-bit mode +is supported by the current implementation of the Linux FE driver). The flags +field is used to mark a request "Read or write" (VIRTIO_I2C_FLAGS_M_RD (bit +1)) or to show dependency between multiple requests +(VIRTIO_I2C_FLAGS_FAIL_NEXT (bit 0)).

As described earlier, the buf is optional. For "write" transactions, it is +pre-filled by the FE driver and read by the BE driver. For "read" transactions, +it is filled by the BE driver and read by the FE driver after the response is +received.

struct virtio_i2c_in_hdr {
+        u8 status;
+};

The in_hdr is represented by the struct virtio_i2c_in_hdr and is used by the +host BE driver to notify the guest with the status of the transfer with +VIRTIO_I2C_MSG_OK or VIRTIO_I2C_MSG_ERR.

Please refer the Virtio I2C +specification +of more details.

Rust I2C backend (BE)

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, +general-purpose programming language designed for performance and safety. It +brings a lot of benefits to the table, especially +memory-safety and safe +concurrency. +It was an easy choice to pick for developing hypervisor agnostic I2C BE driver.

The rust-vmm project, an open-source +initiative, was started back in late 2018, with the aim to share virtualization +packages. The rust-vmm project lets one build custom +Virtual Machine Monitors (VMMs) +and hypervisors. This empowers other projects to quickly develop virtualization +solutions, by reusing the components provided by rust-vmm, and better focus on +key differentiators of their products. The rust-vmm project is organized as a +shared ownership project that so far includes contributions from Alibaba, AWS, +Cloud Base, Google, Intel, Linaro, Red Hat and other individual contributors. +The components provided by rust-vmm are already used by several projects, like +Amazon’s Firecracker +and Intel’s Cloud +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 +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

+Last updated + 2022-01-04 12:48:12 IST +

+ + -- cgit v1.2.3