linux-kernel - RE: [PATCH v10 04/12] iommu: Add attach/detach_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 29 Jul 2022 02:51:02 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Baolu Lu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Christoph Hellwig <hch@...radead.org>,
        "Raj, Ashok" <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        Vinod Koul <vkoul@...nel.org>,
        Eric Auger <eric.auger@...hat.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        Zhangfei Gao <zhangfei.gao@...aro.org>,
        "Zhu, Tony" <tony.zhu@...el.com>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Jean-Philippe Brucker" <jean-philippe@...aro.org>
Subject: RE: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu
 interface

> From: Jason Gunthorpe <jgg@...dia.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