[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bd9b977-500c-602b-8b55-e5f8a13f39ce@linux.intel.com>
Date: Wed, 30 Mar 2022 12:30:15 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Jacob Pan <jacob.jun.pan@...el.com>
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
Jason Gunthorpe <jgg@...dia.com>,
Christoph Hellwig <hch@...radead.org>,
Kevin Tian <kevin.tian@...el.com>,
Ashok Raj <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Jean-Philippe Brucker <jean-philippe@...aro.com>,
linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org
Subject: Re: [PATCH RFC v2 01/11] iommu: Add pasid_bits field in struct
dev_iommu
Hi Jacob,
On 2022/3/30 5:00, Jacob Pan wrote:
> Hi BaoLu,
>
> On Tue, 29 Mar 2022 13:37:50 +0800, Lu Baolu<baolu.lu@...ux.intel.com>
> wrote:
>
>> Use this field to save the pasid/ssid bits that a device is able to
>> support with its IOMMU hardware. It is a generic attribute of a device
>> and lifting it into the per-device dev_iommu struct makes it possible
>> to allocate a PASID for device without calls into the IOMMU drivers.
>> Any iommu driver which suports PASID related features should set this
>> field before features are enabled on the devices.
>>
>> Signed-off-by: Lu Baolu<baolu.lu@...ux.intel.com>
>> ---
>> include/linux/iommu.h | 1 +
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 ++
>> drivers/iommu/intel/iommu.c | 5 ++++-
>> 3 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 6ef2df258673..36f43af0af53 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -368,6 +368,7 @@ struct dev_iommu {
>> struct iommu_fwspec *fwspec;
>> struct iommu_device *iommu_dev;
>> void *priv;
>> + unsigned int pasid_bits;
> pasid_width?
> PCI spec uses "Max PASID Width"
>
My understanding is that this field represents "the pasid bits that the
device is able to use with its IOMMU". This field considers the
capabilities of both device and IOMMU. This is the reason why I put it
in the per-device iommu object and initialize it in the iommu
probe_device() callback.
Best regards,
baolu
Powered by blists - more mailing lists