RE: [RFC] /dev/ioasid uAPI proposal
From: Tian, Kevin
Date: Tue Jun 01 2021 - 03:50:55 EST
> From: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx>
> Sent: Saturday, May 29, 2021 12:23 AM
> > IOASID nesting can be implemented in two ways: hardware nesting and
> > software nesting. With hardware support the child and parent I/O page
> > tables are walked consecutively by the IOMMU to form a nested translation.
> > When it's implemented in software, the ioasid driver is responsible for
> > merging the two-level mappings into a single-level shadow I/O page table.
> > Software nesting requires both child/parent page tables operated through
> > the dma mapping protocol, so any change in either level can be captured
> > by the kernel to update the corresponding shadow mapping.
> Is there an advantage to moving software nesting into the kernel?
> We could just have the guest do its usual combined map/unmap on the child
There are at least two intended usages:
1) From previous discussion looks PPC's window-based scheme can be
better supported with software nesting (a shared IOVA address space
as the parent (shared by all devices) which is nested by multiple windows
as the children (per-device);
2) Some mdev drivers (e.g. kvmgt) may want to do write-protection on
guest data structures (base address programmed to mediated MMIO
register). The base address is IOVA while KVM page-tracking API is
based on GPA. nesting allows finding GPA according to IOVA.