Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <505a0392-57e0-312b-9350-36162e84577c@linux.intel.com>
Date:   Tue, 4 Apr 2023 13:24:45 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Cc:     baolu.lu@linux.intel.com, LKML <linux-kernel@vger.kernel.org>,
        iommu@lists.linux.dev, Robin Murphy <robin.murphy@arm.com>,
        Jason Gunthorpe <jgg@nvidia.com>,
        Joerg Roedel <joro@8bytes.org>, dmaengine@vger.kernel.org,
        vkoul@kernel.org, Will Deacon <will@kernel.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Raj Ashok <ashok.raj@intel.com>,
        "Tian, Kevin" <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        "Zanussi, Tom" <tom.zanussi@intel.com>
Subject: Re: [PATCH v3 6/7] iommu/vt-d: Implement set_dev_pasid domain op
Content-Language: en-US
To:     Jacob Pan <jacob.jun.pan@linux.intel.com>
References: <20230331231137.1947675-1-jacob.jun.pan@linux.intel.com>
 <20230331231137.1947675-7-jacob.jun.pan@linux.intel.com>
 <a63e70cc-8890-bb99-3326-0b19e81ea92e@linux.intel.com>
 <20230403144827.7b2c1ccb@jacob-builder>
From:   Baolu Lu <baolu.lu@linux.intel.com>
In-Reply-To: <20230403144827.7b2c1ccb@jacob-builder>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/4/23 5:48 AM, Jacob Pan wrote:
> On Sat, 1 Apr 2023 21:48:36 +0800, Baolu Lu<baolu.lu@linux.intel.com>
> wrote:
> 
>> On 2023/4/1 7:11, Jacob Pan wrote:
>>> Devices that use ENQCMDS to submit work on buffers mapped by DMA API
>>> must attach a PASID to the default domain of the device. In preparation
>>> for this use case, this patch implements set_dev_pasid() for the
>>> default_domain_ops.
>>>
>>> If the device context has not been set up prior to this call, this will
>>> set up the device context in addition to PASID attachment.
>>>
>>> Signed-off-by: Jacob Pan<jacob.jun.pan@linux.intel.com>
>>> ---
>>>    drivers/iommu/intel/iommu.c | 21 +++++++++++++++++++++
>>>    1 file changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>>> index 52b9d0d3a02c..1ad9c5a4bd8f 100644
>>> --- a/drivers/iommu/intel/iommu.c
>>> +++ b/drivers/iommu/intel/iommu.c
>>> @@ -4784,6 +4784,26 @@ static void intel_iommu_remove_dev_pasid(struct
>>> device *dev, ioasid_t pasid) domain_detach_iommu(dmar_domain,
>>> info->iommu); }
>>>    
>>> +static int intel_iommu_attach_device_pasid(struct iommu_domain *domain,
>>> +					   struct device *dev,
>>> ioasid_t pasid) +{
>>> +	struct device_domain_info *info = dev_iommu_priv_get(dev);
>>> +	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
>>> +	struct intel_iommu *iommu = info->iommu;
>>> +	int ret;
>>> +
>>> +	if (!pasid_supported(iommu))
>>> +		return -ENODEV;
>> As the domain ID will be set to the pasid entry, need to get a refcount
>> of the domain ID. Call domain_attach_iommu() here, and release it after
>> the pasid entry is torn down.
> dmar_domain_attach_device_pasid() below will call domain_attach_iommu() and
> release in intel_iommu_remove_dev_pasid(). The previous patch has
> consolidated the code path with device attachment.
> would it be sufficient?

It's fine. Sorry, I overlooked this.

Best regards,
baolu