lkml.org 
[lkml]   [2022]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/7] iommu cleanup and refactoring
    On Tue, Jan 25, 2022 at 02:48:02PM +0000, Robin Murphy wrote:

    > Agreed, certainly an IOMMU_DOMAIN_SVA type that can both encapsulate the mm
    > and effectively replace iommu_sva seems like a logical and fairly small next
    > step. We already have the paradigm of different domain types supporting
    > different ops, so initially an SVA domain would simply allow bind/unbind
    > rather than attach/detach/map/unmap.

    I hope we can quickly get to a PASID enabled generic attach/detach
    scheme - we really need this to do the uAPI part of this interface.

    > they are fundamentally different things in their own right, and the ideal
    > API should give us the orthogonality to also bind a device to an SVA domain
    > without PASID (e.g. for KVM stage 2, or userspace assignment of simpler
    > fault/stall-tolerant devices), or attach PASIDs to regular iommu_domains.

    Yes, these are orthogonal things. A iommu driver that supports PASID
    ideally should support PASID enabled attach/detatch for every
    iommu_domain type it supports.

    SVA should not be entangled with PASID beyond that SVA is often used
    with PASID - a SVA iommu_domain should be fully usable with a RID too.

    I'm hoping to see the core iommu code provide some simplified "SVA"
    API that under the covers creates a SVA domain and then does a normal
    PASID attach using the global PASID in the mm_struct - the
    driver should not care what, or even if, PASID is used for a SVA
    domain.

    Jason

    \
     
     \ /
      Last update: 2022-01-25 16:20    [W:3.184 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site