[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d1e2178-ac4c-a864-59b4-d297a3366f6a@linux.intel.com>
Date: Wed, 25 May 2022 10:38:24 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: "Tian, Kevin" <kevin.tian@...el.com>,
Jason Gunthorpe <jgg@...dia.com>
Cc: 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>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jean-Philippe Brucker <jean-philippe@...aro.org>
Subject: Re: [PATCH v7 03/10] iommu/sva: Add iommu_sva_domain support
On 2022/5/25 08:44, Tian, Kevin wrote:
>> From: Jason Gunthorpe <jgg@...dia.com>
>> Sent: Tuesday, May 24, 2022 9:39 PM
>>
>> On Tue, May 24, 2022 at 09:39:52AM +0000, Tian, Kevin wrote:
>>>> From: Lu Baolu <baolu.lu@...ux.intel.com>
>>>> Sent: Thursday, May 19, 2022 3:21 PM
>>>>
>>>> The iommu_sva_domain represents a hardware pagetable that the
>> IOMMU
>>>> hardware could use for SVA translation. This adds some infrastructure
>>>> to support SVA domain in the iommu common layer. It includes:
>>>>
>>>> - Add a new struct iommu_sva_domain and new IOMMU_DOMAIN_SVA
>>>> domain
>>>> type.
>>>> - Add a new domain ops pointer in iommu_ops. The IOMMU drivers that
>>>> support SVA should provide the callbacks.
>>>> - Add helpers to allocate and free an SVA domain.
>>>> - Add helpers to set an SVA domain to a device and the reverse
>>>> operation.
>>>>
>>>> Some buses, like PCI, route packets without considering the PASID value.
>>>> Thus a DMA target address with PASID might be treated as P2P if the
>>>> address falls into the MMIO BAR of other devices in the group. To make
>>>> things simple, the attach/detach interfaces only apply to devices
>>>> belonging to the singleton groups, and the singleton is immutable in
>>>> fabric i.e. not affected by hotplug.
>>>>
>>>> The iommu_set/block_device_pasid() can be used for other purposes,
>>>> such as kernel DMA with pasid, mediation device, etc. Hence, it is put
>>>> in the iommu.c.
>>>
>>> usually we have 'set/clear' pair or 'allow/block'. Having 'set' paired
>>> with 'block' doesn't read very clearly.
>>
>> I thought we agreed we'd use the blocking domain for this? Why did it
>> go back to an op?
>>
>
> Probably it's based on following discussion:
>
> https://lore.kernel.org/all/c8492b29-bc27-ae12-d5c4-9fbbc797e310@linux.intel.com/
>
> --
>> FWIW from my point of view I'm happy with having a .detach_dev_pasid op
>> meaning implicitly-blocked access for now.
>
> If this is the path then lets not call it attach/detach
> please. 'set_dev_pasid' and 'set_dev_blocking_pasid' are clearer
> names.
Yes. Learning from above discussion, we are about to implement the
set_dev_pasid and blocking domain in parallel. We will convert all
the callback names to set_dev and set_dev_pasid after blocking domain
support is merged.
> --
>
> Looks Baolu chooses this path and plans to use the blocking domain
> later.
Yes. I have already started to implement the blocking domain in Intel
driver. With it as an example, we can extend it to other possible IOMMU
drivers.
Best regards,
baolu
Powered by blists - more mailing lists