> From: Liu, Yi L
> Sent: Sunday, September 19, 2021 2:38 PM
[...]
> [Series Overview]
>
> * Basic skeleton:
> 0001-iommu-iommufd-Add-dev-iommu-core.patch
>
> * VFIO PCI creates device-centric interface:
> 0002-vfio-Add-device-class-for-dev-vfio-devices.patch
>
Document the /dev/iommu framework for user.
Open:
Do we want to document /dev/iommu in Documentation/userspace-api/iommu.rst?
Existing iommu.rst is for the vSVA interfaces, honestly, may need to rewrite
this doc entirely.
Signed-off-by: Kevin Tian
Signed-off-by: Liu Yi L
---
From: Lu Baolu
Expose per-device IOMMU attributes to the upper layers.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index
[HACK. will fix in v2]
This patch introduces vfio type1v2-equivalent interface to userspace. Due
to aforementioned hack, iommufd currently calls exported vfio symbols to
handle map/unmap requests from the user.
Signed-off-by: Liu Yi L
---
drivers/iommu/iommufd/iommufd.c | 104
[HACK. will fix in v2]
IOVA range is critical info for userspace to manage DMA for an I/O address
space. This patch reports the valid iova range info of a given device.
Due to aforementioned hack, this info comes from the hacked vfio type1
driver. To follow the same format in vfio, we also
[HACK. will fix in v2]
There are two options to impelement vfio type1v2 mapping semantics in
/dev/iommu.
One is to duplicate the related code from vfio as the starting point,
and then merge with vfio type1 at a later time. However vfio_iommu_type1.c
has over 3000LOC with ~80% related to dma
This patch adds interface for userspace to attach device to specified
IOASID.
Note:
One device can only be attached to one IOASID in this version. This is
on par with what vfio provides today. In the future this restriction can
be relaxed when multiple I/O address spaces are supported per device
An I/O address space takes effect in the iommu only after it's attached
by a device. This patch provides iommufd_device_[de/at]tach_ioasid()
helpers for this purpose. One device can be only attached to one ioasid
at this point, but one ioasid can be attached by multiple devices.
The caller
From: Lu Baolu
These two helpers could be used when 1) the iommu group is singleton,
or 2) the upper layer has put the iommu group into the secure state by
calling iommu_device_init_user_dma().
As we want the iommufd design to be a device-centric model, we want to
remove any group knowledge in
As aforementioned, userspace should check extension for what formats
can be specified when allocating an IOASID. This patch adds such
interface for userspace. In this RFC, iommufd reports EXT_MAP_TYPE1V2
support and no no-snoop support yet.
Signed-off-by: Liu Yi L
---
This patch adds IOASID allocation/free interface per iommufd. When
allocating an IOASID, userspace is expected to specify the type and
format information for the target I/O page table.
This RFC supports only one type (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2),
implying a kernel-managed I/O page table
After a device is bound to the iommufd, userspace can use this interface
to query the underlying iommu capability and format info for this device.
Based on this information the user then creates I/O address space in a
compatible format with the to-be-attached devices.
Device cookie which is
From: Lu Baolu
This exposes PAGE_SIZE and ADDR_WIDTH attributes. The iommufd could use
them to define the IOAS.
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index
This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind the vfio
device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface is provided
because it's implicitly done when the device fd is closed.
In concept a vfio device can be bound to multiple iommufds, each hosting
a subset of I/O
Under the /dev/iommu model, iommufd provides the interface for I/O page
tables management such as dma map/unmap. However, it cannot work
independently since the device is still owned by the device-passthrough
frameworks (VFIO, vDPA, etc.) and vice versa. Device-passthrough frameworks
should build
From: Lu Baolu
This extends iommu core to manage security context for passthrough
devices. Please bear a long explanation for how we reach this design
instead of managing it solely in iommufd like what vfio does today.
Devices which cannot be isolated from each other are organized into an
iommu
This patch exposes the device-centric interface for vfio-pci devices. To
be compatiable with existing users, vfio-pci exposes both legacy group
interface and device-centric interface.
As explained in last patch, this change doesn't apply to devices which
cannot be forced to snoop cache by their
From: Lu Baolu
This provides an interface for upper layers to get the per-device iommu
attributes.
int iommu_device_get_info(struct device *dev,
enum iommu_devattr attr, void *data);
The first attribute (IOMMU_DEV_INFO_FORCE_SNOOP) is added. It tells if
the
With /dev/vfio/devices introduced, now a vfio device driver has three
options to expose its device to userspace:
a) only legacy group interface, for devices which haven't been moved to
iommufd (e.g. platform devices, sw mdev, etc.);
b) both legacy group interface and new device-centric
This patch introduces a new interface (/dev/vfio/devices/$DEVICE) for
userspace to directly open a vfio device w/o relying on container/group
(/dev/vfio/$GROUP). Anything related to group is now hidden behind
iommufd (more specifically in iommu core by this RFC) in a device-centric
manner.
In
/dev/iommu aims to provide a unified interface for managing I/O address
spaces for devices assigned to userspace. This patch adds the initial
framework to create a /dev/iommu node. Each open of this node returns an
iommufd. And this fd is the handle for userspace to initiate its I/O
address space
Linux now includes multiple device-passthrough frameworks (e.g. VFIO and
vDPA) to manage secure device access from the userspace. One critical task
of those frameworks is to put the assigned device in a secure, IOMMU-
protected context so user-initiated DMAs are prevented from doing harm to
the
22 matches
Mail list logo
