lkml.org 
[lkml]   [2021]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2021-06-03 14:50    [W:4.700 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site