lkml.org 
[lkml]   [2022]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu interface
Date
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, July 28, 2022 8:00 PM
>
> On Thu, Jul 28, 2022 at 03:06:47AM +0000, Tian, Kevin wrote:
>
> > > Then we don't need this weirdo check in the core iommu code at all.
> >
> > and then we could also move group->pasid_array to device->pasid_array
> > with this approach. Though the end result doesn't change i.e. still only
> > the singleton group can enable pasid the iommu core can just stick to
> > the device manner now.
>
> I don't see why, the group is still logically the unit of attachment
> in the iommu area, and if we have a multi-device group it just means
> we iterate over all the devices in the group when doing pasid set, no
> different than a RID.

Probably I overthought about this.

To enable PASID in a multi-device group one prerequisite is to reserve
P2P ranges of the group in the related address space (let's assume
there is a way to do that reservation). In this case even w/o ACS in the
switch port all DMA requests from the group can be still routed to
upstream.

Then for a group created due to lacking of ACS looks we can still have
per-device PASID tables in the group.

But for a group created due to RID mess e.g. PCI bridge the PASID table
has to be shared by the entire group. So yes, from this angle leaving
one table per group is a simpler thing to do, especially when it's
unclear whether there is real demand to enable PASID for multi-device
group. 😊

Thanks
Kevin
\
 
 \ /
  Last update: 2022-07-29 04:51    [W:0.122 / U:3.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site