diff options
| author | Viresh Kumar <viresh.kumar@linaro.org> | 2022-01-04 13:02:15 +0530 |
|---|---|---|
| committer | Viresh Kumar <viresh.kumar@linaro.org> | 2022-01-04 13:02:15 +0530 |
| commit | c8208ea70f8804d6c4eb4b1aef9c90f24ea3d5be (patch) | |
| tree | 9693e0987fdf5a5d88d403f103d8c31179b6770c | |
| parent | 9ff1c58eee141b912fd39c36ae3919398d33ce4c (diff) | |
updates
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
| -rw-r--r-- | boot_constraint/.boot_constraint_orig.txt.swp | bin | 16384 -> 0 bytes | |||
| -rw-r--r-- | rust/.gpio.txt.swp | bin | 36864 -> 36864 bytes | |||
| -rw-r--r-- | rust/gpio.html | 147 | ||||
| -rw-r--r-- | rust/gpio.txt | 135 |
4 files changed, 273 insertions, 9 deletions
diff --git a/boot_constraint/.boot_constraint_orig.txt.swp b/boot_constraint/.boot_constraint_orig.txt.swp Binary files differdeleted file mode 100644 index 17df0f4..0000000 --- a/boot_constraint/.boot_constraint_orig.txt.swp +++ /dev/null diff --git a/rust/.gpio.txt.swp b/rust/.gpio.txt.swp Binary files differindex 6239ba2..5523aa2 100644 --- a/rust/.gpio.txt.swp +++ b/rust/.gpio.txt.swp 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 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<meta name="generator" content="AsciiDoc 9.0.0rc1">
+<title>Rust based vhost-user I2C backend</title>
+</head>
+<body>
+<h1>Rust based vhost-user I2C backend</h1>
+<p>
+</p>
+<a name="preamble"></a>
+<p>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. <a href="https://www.linaro.org/projects/#automotive_STR">Linaro’s Project
+Stratos</a> is working towards developing hypervisor agnostic abstract devices
+leveraging virtio and extending hypervisor interfaces and standards to allow all
+architectures.</p>
+<p>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.</p>
+<p>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
+<a href="https://github.com/oasis-tcs/virtio-spec">virtio specification</a>, which is
+maintained by <a href="https://www.oasis-open.org/org/">OASIS</a>. 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.</p>
+<p>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.</p>
+<hr>
+<h2><a name="_virtio_i2c_specification"></a>Virtio I2C Specification</h2>
+<p>The Virtio
+<a href="https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex">specification</a>
+for I2C and the Linux
+<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-virtio.c">i2c-virtio</a>
+driver are upstreamed by Jie Deng (Intel), who tested his work with the
+<a href="https://projectacrn.org">ACRN</a> 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.</p>
+<p>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
+<code>VIRTIO_I2C_F_ZERO_LENGTH_REQUEST</code> 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
+<code>struct virtio_i2c_req</code>, 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.</p>
+<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="4"><tr><td>
+<pre><code>struct virtio_i2c_req {
+ struct virtio_i2c_out_hdr out_hdr;
+ u8 buf[];
+ struct virtio_i2c_in_hdr in_hdr;
+};</code></pre>
+</td></tr></table>
+<p>Each I2C virtio request consists of an <code>out_hdr</code> (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 <code>in_hdr</code> (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.</p>
+<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="4"><tr><td>
+<pre><code>struct virtio_i2c_out_hdr {
+ le16 addr;
+ le16 padding;
+ le32 flags;
+};</code></pre>
+</td></tr></table>
+<p>The <code>out_hdr</code> is represented by the <code>struct virtio_i2c_out_hdr</code>. The <code>addr</code>
+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 <code>flags</code>
+field is used to mark a request "Read or write" (<code>VIRTIO_I2C_FLAGS_M_RD</code> (bit
+1)) or to show dependency between multiple requests
+(<code>VIRTIO_I2C_FLAGS_FAIL_NEXT</code> (bit 0)).</p>
+<p>As described earlier, the <code>buf</code> 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.</p>
+<table border="0" bgcolor="#e8e8e8" width="100%" cellpadding="4"><tr><td>
+<pre><code>struct virtio_i2c_in_hdr {
+ u8 status;
+};</code></pre>
+</td></tr></table>
+<p>The <code>in_hdr</code> is represented by the <code>struct virtio_i2c_in_hdr</code> and is used by the
+host BE driver to notify the guest with the status of the transfer with
+<code>VIRTIO_I2C_MSG_OK</code> or <code>VIRTIO_I2C_MSG_ERR</code>.</p>
+<p>Please refer the Virtio I2C
+<a href="https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex">specification</a>
+of more details.</p>
+<hr>
+<h2><a name="_rust_i2c_backend_be"></a>Rust I2C backend (BE)</h2>
+<p>Rust is the next big thing disrupting the Linux world and most of us are already
+aware of the <a href="https://github.com/Rust-for-Linux">Rust for Linux</a> 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
+<a href="https://en.wikipedia.org/wiki/Memory_safety">memory-safety</a> and safe
+<a href="https://en.wikipedia.org/wiki/Concurrency_(computer_science)">concurrency</a>.
+It was an easy choice to pick for developing hypervisor agnostic I2C BE driver.</p>
+<p>The <a href="https://github.com/rust-vmm">rust-vmm</a> 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
+<a href="https://en.wikipedia.org/wiki/Hypervisor">Virtual Machine Monitors (VMMs)
+and hypervisors</a>. 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 <a href="https://github.com/firecracker-microvm/firecracker">Firecracker</a>
+and Intel’s <a href="https://github.com/cloud-hypervisor/cloud-hypervisor">Cloud
+Hypervisor</a>. 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.</p>
+<p>One such component is the
+<a href="https://crates.io/crates/vhost-user-backend">vhost-user-backend</a> crate,
+which has recently made its way to <a href="https://crates.io/">crates.io</a>, the Rust
+community’s crate registry. The vhost-user-backend crate provides a framework to implement the vhost-user backend services</p>
+<p></p>
+<p></p>
+<hr><p><small>
+Last updated
+ 2022-01-04 12:48:12 IST
+</small></p>
+</body>
+</html>
diff --git a/rust/gpio.txt b/rust/gpio.txt index 354931c..2b128dd 100644 --- a/rust/gpio.txt +++ b/rust/gpio.txt @@ -1,11 +1,11 @@ -Rust based Virtio 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. link:https://www.linaro.org/projects/#automotive_STR[Linaro's project +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 architectures. @@ -16,16 +16,133 @@ 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 back-end (BE) virtio driver, implemented in the hypervisor running on the host, +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 front-end (FE) virtio driver compatible with the virtio +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 set of predefined protocols as defined in the +on a set of predefined protocols as defined by the link:https://github.com/oasis-tcs/virtio-spec[virtio specification], which is maintained by link:https://www.oasis-open.org/org/[OASIS]. The FE driver can -implement zero or more Virtual queues ("virtqueues"), as defined by the virtio +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 only -need to parse the virtqueue structures to obtain the requests and process them. +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 +link:https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex[specification] +for I2C and the Linux +link:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-virtio.c[i2c-virtio] +driver are upstreamed by Jie Deng (Intel), who tested his work with the +link:https://projectacrn.org[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 +link:https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex[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 link:https://github.com/Rust-for-Linux[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 +link:https://en.wikipedia.org/wiki/Memory_safety[memory-safety] and safe +link:https://en.wikipedia.org/wiki/Concurrency_(computer_science)[concurrency]. +It was an easy choice to pick for developing hypervisor agnostic I2C BE driver. + +The link:https://github.com/rust-vmm[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 +link:https://en.wikipedia.org/wiki/Hypervisor[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 link:https://github.com/firecracker-microvm/firecracker[Firecracker] +and Intel's link:https://github.com/cloud-hypervisor/cloud-hypervisor[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 +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 |