OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [PATCH 0/4] virtio-iommu: Support page tables


Add page table support to the virtio-iommu specification, to enable
acceleration and later Shared Virtual Memory.

The interface currently offered by virtio-iommu is simple to implement
and sufficiently efficient for solutions based on static mappings, such
as DPDK running in guest userspace. While that's an essential use-case
for virtio-iommu, it is not the only DMA remapping usage, and the
MAP/UNMAP interface performs rather poorly for dynamic mappings.
Unsurprisingly a given vIOMMU model cannot be simple, efficient and
secure for all possible use-cases. It's always a compromise.

This extension adds:

* New PROBE properties that describe table formats available for each
  endpoints.
* An ATTACH_TABLE request to be used in place of an ATTACH, that
  provides a guest-physical address to a table.
* An INVALIDATE request to signal destructive changes.

Those tables may be:

(1) Page tables that are read directly by the hardware IOMMU, for
  hardware endpoints. An example for Arm SMMU is given in patch 4. The
  driver writes mappings into the table, and sends invalidations when
  removing mappings that could have been cached in an IOTLB. This
  divides the number of context switches to the host by at least two
  (much more with lazy invalidation), and with a vhost IOMMU the
  invalidation itself should be relatively cheap compared to an emulated
  viommu.

  I don't expect a large proliferation of table formats because they are
  relatively stable. A few extensible formats is more likely: two tables
  for Arm until they run out of PTE bits, one or two page tables for
  x86, and a couple for other architectures.

(2) Tables that are read by a software component performing DMA, for
  emulated and paravirtual endpoints. These could be your garden-variety
  page tables from (1) but being paravirtual we have the opportunity to
  design more efficient solutions. For example a virtio/vhost endpoint
  accesses rings often and leaf buffers once. If the virtio-iommu device
  avoids caching leaf buffers, the driver does not need to send
  invalidations and we get almost no context switches for vIOMMU
  operations. A purposely designed page table can provide a handshake
  between device and driver to avoid sending invalidations for uncached
  mappings.

(3) Tables that complement the MAP_UNMAP interface to help reduce
  context switches. The coIOMMU model [1] provides a DMA tracking table
  for co-operative pinning.


An example driver implementation was submitted by Vivek Gautam [2],
based on an older version of this extension (0.10-dev03). Since then
I've reworked some of the structures and improved the wording. To ease
review I uploaded a PDF with these changes, plus one with diff colors,
here:

https://jpbrucker.net/virtio-iommu/spec/virtio-iommu-v0.13.pdf
https://jpbrucker.net/virtio-iommu/spec/virtio-iommu-diff-v0.12-v0.13.pdf


[1] https://www.usenix.org/system/files/atc20-tian.pdf
[2] https://lore.kernel.org/linux-iommu/20210115121342.15093-1-vivek.gautam@arm.com/

Jean-Philippe Brucker (4):
  virtio-iommu: Add ATTACH_TABLE request
  virtio-iommu: Add INVALIDATE request
  virtio-iommu: Add PROBE properties for tables
  virtio-iommu: Add Arm 64-bit page tables

 introduction.tex |   6 +
 virtio-iommu.tex | 564 ++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 560 insertions(+), 10 deletions(-)

-- 
2.30.0



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]