Skip to content

Commit 19e5b83

Browse files
committed
ioctls: refine README.md and Cargo.toml
Refine README.md and Cargo.toml, prepare for publishing. Signed-off-by: Liu Jiang <[email protected]>
1 parent da94b5a commit 19e5b83

File tree

4 files changed

+84
-28
lines changed

4 files changed

+84
-28
lines changed

README.md

+27
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Safe wrappers for VFIO
2+
3+
## Design
4+
5+
This repository provides safe wrappers over the
6+
[VFIO driver framework](https://www.kernel.org/doc/Documentation/vfio.txt).
7+
8+
Many modern systems now provide DMA and interrupt remapping facilities to help ensure I/O devices behave within the boundaries they’ve been allotted. This includes x86 hardware with AMD-Vi and Intel VT-d, POWER systems with Partitionable Endpoints (PEs) and embedded PowerPC systems such as Freescale PAMU. The VFIO driver is an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment. In other words, the VFIO framework allows safe, non-privileged, userspace drivers.
9+
10+
Why do we want that? Virtual machines often make use of direct device access (“device assignment”) when configured for the highest possible I/O performance. From a device and host perspective, this simply turns the VM into a userspace driver, with the benefits of significantly reduced latency, higher bandwidth, and direct use of bare-metal device drivers.
11+
12+
Devices are the main target of any I/O driver. Devices typically create a programming interface made up of I/O accesses, interrupts, and DMA. Without going into the details of each of these, DMA is by far the most critical aspect for maintaining a secure environment as allowing a device read-write access to system memory imposes the greatest risk to the overall system integrity.
13+
14+
To help mitigate this risk, many modern IOMMUs now incorporate isolation properties into what was, in many cases, an interface only meant for translation (ie. solving the addressing problems of devices with limited address spaces). With this, devices can now be isolated from each other and from arbitrary memory access, thus allowing things like secure direct assignment of devices into virtual machines.
15+
16+
While for the most part an IOMMU may have device level granularity, any system is susceptible to expose a reduced granularity. The IOMMU API therefore supports a notion of IOMMU groups. A group is a set of devices which is isolated from all other devices in the system. Groups are therefore the unit of ownership used by VFIO.
17+
18+
While the group is the minimum granularity that must be used to ensure secure user access, it’s not necessarily the preferred granularity. In IOMMUs which make use of page tables, it may be possible to share a set of page tables between different groups, reducing the overhead both to the platform (reduced TLB thrashing, reduced duplicate page tables), and to the user (programming only a single set of translations). For this reason, VFIO makes use of a container class, which may hold one or more groups. A container is created by simply opening the /dev/vfio/vfio character device.
19+
20+
## Usage
21+
This repository provides two crates to use the VFIO framework, please refer to crate documentations for detail information.
22+
- [vfio-bindings](https://github.com/rust-vmm/vfio-ioctls/tree/ioctls/crates/vfio-bindings): a rust FFI bindings to VFIO generated using [bindgen](https://crates.io/crates/bindgen).
23+
- [vfio-ioctls](https://github.com/rust-vmm/vfio-ioctls/tree/ioctls/crates/vfio-ioctls): a group of safe wrappers over the [VFIO APIs](https://github.com/torvalds/linux/blob/master/include/uapi/linux/vfio.h).
24+
25+
## License
26+
27+
This code is licensed under Apache-2.0 or BSD-3-Clause.

crates/vfio-ioctls/Cargo.toml

+4-2
Original file line numberDiff line numberDiff line change
@@ -2,10 +2,12 @@
22
name = "vfio-ioctls"
33
version = "0.1.0"
44
authors = ["The Cloud Hypervisor Authors", "Liu Jiang <[email protected]>"]
5-
description = "Safe wrappers over VFIO ioctls"
6-
keywords = ["vfio"]
75
license = "Apache-2.0 OR BSD-3-Clause"
6+
description = "Safe wrappers over VFIO ioctls"
7+
repository = "https://github.com/rust-vmm/vfio"
8+
readme = "README.md"
89
edition = "2018"
10+
keywords = ["vfio"]
911

1012
[features]
1113
default = ["kvm"]

crates/vfio-ioctls/README.md

+50-23
Original file line numberDiff line numberDiff line change
@@ -1,41 +1,68 @@
1-
# Crate Name
1+
# vfio-ioctls
22

33
## Design
44

5-
TODO: This section should have a high-level design of the crate.
5+
The [VFIO driver framework](https://www.kernel.org/doc/Documentation/vfio.txt)
6+
provides unified APIs for direct device access. It is an IOMMU/device-agnostic framework for
7+
exposing direct device access to user space in a secure, IOMMU-protected environment.
8+
This framework is used for multiple devices, such as GPUs, network adapters, and compute
9+
accelerators. With direct device access, virtual machines or user space applications have
10+
direct access to the physical device.
611

7-
Some questions that might help in writing this section:
8-
- What is the purpose of this crate?
9-
- What are the main components of the crate? How do they interact which each
10-
other?
12+
The VFIO framework is originally developed on Linux system, and later Microsoft HyperVisor
13+
technology provides a compatible implementation. Therefore the VFIO framework is supported
14+
by both Linux and Microsoft HyperVisor.
15+
16+
The `vfio-ioctls` crate is a safe wrapper over the VFIO APIs. It provides three classes of structs:
17+
- `VfioContainer`: a safe wrapper over a VFIO container object, and acts a container object
18+
to associate `VfioDevice` objects with IOMMU domains.
19+
- `VfioDevice`: a wrapper over a VFIO device object, provide methods to access the underlying
20+
hardware device.
21+
- `VfioIrq/VfioRegion`: describes capabilities/resources about a `VfioDevice` object.
1122

1223
## Usage
1324

14-
TODO: This section describes how the crate is used.
25+
The `vfio-ioctls` crate may be used to support following usage scenarios:
26+
- Direct device assignment to virtual machine based on Linux KVM, with default features.
27+
- Direct device assignment to virtual machine based on Microsoft HyperVisor, with `--no-default-features --features=mshv`.
28+
- User mode device drivers, with `--no-default-features`.
29+
30+
First, add the following to your Cargo.toml:
31+
```toml
32+
vfio-ioctls = "0.1"
33+
```
34+
Next, add this to your crate root:
35+
36+
```rust
37+
extern crate vfio_ioctls;
38+
```
39+
40+
By default vfio-ioctls has the `kvm` feature enabled. You may turn off the default features by
41+
`default-features = false`. To enable feature `mshv`,
42+
```toml
43+
vfio-ioctls = { version = "0.1", default-features = false, features = ["mshv"]}
44+
```
1545

16-
Some questions that might help in writing this section:
17-
- What traits do users need to implement?
18-
- Does the crate have any default/optional features? What is each feature
19-
doing?
20-
- Is this crate used by other rust-vmm components? If yes, how?
2146

2247
## Examples
2348

24-
TODO: Usage examples.
49+
To create VFIO device object for user mode drivers,
2550

2651
```rust
27-
use my_crate;
52+
use std::sync::Arc;
53+
use vfio_ioctls::{VfioContainer, VfioDevice};
54+
55+
fn create_vfio_device() {
56+
// TODO: change to your device's path
57+
let device_path = "/sys/bus/pci/devices/00:03.0";
58+
let vfio_container = Arc::new(VfioContainer::new(()).unwrap());
59+
let vfio_dev = VfioDevice::new(&Path::new(device_path), vfio_container.clone()).unwrap();
60+
let irqs = vfio_dev.max_interrupts();
2861

29-
...
62+
assert!(irqs > 0);
63+
}
3064
```
3165

3266
## License
3367

34-
**!!!NOTICE**: The BSD-3-Clause license is not included in this template.
35-
The license needs to be manually added because the text of the license file
36-
also includes the copyright. The copyright can be different for different
37-
crates. If the crate contains code from CrosVM, the crate must add the
38-
CrosVM copyright which can be found
39-
[here](https://chromium.googlesource.com/chromiumos/platform/crosvm/+/master/LICENSE).
40-
For crates developed from scratch, the copyright is different and depends on
41-
the contributors.
68+
This code is licensed under Apache-2.0 or BSD-3-Clause.

crates/vfio-ioctls/src/vfio_device.rs

+3-3
Original file line numberDiff line numberDiff line change
@@ -500,7 +500,7 @@ pub enum VfioRegionInfoCap {
500500
Nvlink2Lnkspd(VfioRegionInfoCapNvlink2Lnkspd),
501501
}
502502

503-
/// Information abour VFIO MMIO region.
503+
/// Information about VFIO MMIO region.
504504
#[derive(Clone, Debug)]
505505
pub struct VfioRegion {
506506
pub(crate) flags: u32,
@@ -509,7 +509,7 @@ pub struct VfioRegion {
509509
pub(crate) caps: Vec<VfioRegionInfoCap>,
510510
}
511511

512-
/// Information abour VFIO interrupts.
512+
/// Information about VFIO interrupts.
513513
#[derive(Copy, Clone, Debug, PartialEq)]
514514
pub struct VfioIrq {
515515
/// Flags for irq.
@@ -716,7 +716,7 @@ impl AsRawFd for VfioDeviceInfo {
716716
}
717717
}
718718

719-
/// Vfio device to access underlying hardware devices.
719+
/// A safe wrapper over a Vfio device to access underlying hardware device.
720720
///
721721
/// The VFIO device API includes ioctls for describing the device, the I/O regions and their
722722
/// read/write/mmap offsets on the device descriptor, as well as mechanisms for describing and

0 commit comments

Comments
 (0)