Messages in this thread | | | Date | Thu, 3 Jun 2021 09:49:23 -0300 | From | Jason Gunthorpe <> | Subject | Re: [RFC] /dev/ioasid uAPI proposal |
| |
On Thu, Jun 03, 2021 at 07:17:23AM +0000, Tian, Kevin wrote: > > From: David Gibson <david@gibson.dropbear.id.au> > > Sent: Wednesday, June 2, 2021 2:15 PM > > > [...] > > > An I/O address space takes effect in the IOMMU only after it is attached > > > to a device. The device in the /dev/ioasid context always refers to a > > > physical one or 'pdev' (PF or VF). > > > > What you mean by "physical" device here isn't really clear - VFs > > aren't really physical devices, and the PF/VF terminology also doesn't > > extent to non-PCI devices (which I think we want to consider for the > > API, even if we're not implemenenting it any time soon). > > Yes, it's not very clear, and more in PCI context to simplify the > description. A "physical" one here means an PCI endpoint function > which has a unique RID. It's more to differentiate with later mdev/ > subdevice which uses both RID+PASID. Naming is always a hard > exercise to me... Possibly I'll just use device vs. subdevice in future > versions.
Using PCI words:
A "physical" device is RID matching.
A "subdevice" is (RID, PASID) matching.
A "SW mdev" is performing DMA isolation in a device specific way - all DMA's from the device are routed to the hypervisor's IOMMU page tables.
Jason
| |