All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Yang, Weijiang" <weijiang.yang@intel.com>, Yi Liu <yi.l.liu@intel.com>
Cc: baolu.lu@linux.intel.com, robin.murphy@arm.com,
	kevin.tian@intel.com, jgg@nvidia.com, alex.williamson@redhat.com,
	joro@8bytes.org, cohuck@redhat.com, eric.auger@redhat.com,
	nicolinc@nvidia.com, kvm@vger.kernel.org, mjrosato@linux.ibm.com,
	chao.p.peng@linux.intel.com, yi.y.sun@linux.intel.com,
	peterx@redhat.com, jasowang@redhat.com,
	shameerali.kolothum.thodi@huawei.com, lulu@redhat.com,
	suravee.suthikulpanit@amd.com, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	zhenzhong.duan@intel.com, joao.m.martins@oracle.com,
	xin.zeng@intel.com, yan.y.zhao@intel.com
Subject: Re: [PATCH 8/8] iommu/vt-d: Add set_dev_pasid callback for nested domain
Date: Thu, 14 Dec 2023 21:33:46 +0800	[thread overview]
Message-ID: <4e08dc77-82ce-40ce-8a0c-ac9016186c23@linux.intel.com> (raw)
In-Reply-To: <a19031b0-7c30-45e6-b171-c53e3578b867@intel.com>

On 2023/12/14 10:55, Yang, Weijiang wrote:
> On 11/27/2023 2:34 PM, Yi Liu wrote:
>> From: Lu Baolu <baolu.lu@linux.intel.com>
>>
>> This allows the upper layers to set a nested type domain to a PASID of a
>> device if the PASID feature is supported by the IOMMU hardware.
>>
>> The set_dev_pasid callback for non-nest domain has already be there, so
>> this only needs to add it for nested domains.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
>> ---
>>   drivers/iommu/intel/nested.c | 47 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 47 insertions(+)
>>
>> diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c
>> index 44ad48db7ea0..f6f687750104 100644
>> --- a/drivers/iommu/intel/nested.c
>> +++ b/drivers/iommu/intel/nested.c
>> @@ -68,6 +68,52 @@ static int intel_nested_attach_dev(struct 
>> iommu_domain *domain,
>>       return 0;
>>   }
>> +static int intel_nested_set_dev_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;
>> +    struct dev_pasid_info *dev_pasid;
>> +    unsigned long flags;
>> +    int ret = 0;
>> +
>> +    if (!pasid_supported(iommu))
>> +        return -EOPNOTSUPP;
>> +
>> +    if (iommu->agaw < dmar_domain->s2_domain->agaw)
>> +        return -EINVAL;
>> +
>> +    ret = 
>> prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev);
>> +    if (ret)
>> +        return ret;
>> +
>> +    dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL);
>> +    if (!dev_pasid)
>> +        return -ENOMEM;
>> +
>> +    ret = domain_attach_iommu(dmar_domain, iommu);
>> +    if (ret)
>> +        goto err_free;
>> +
>> +    ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain);
>> +    if (ret)
>> +        goto err_detach_iommu;
>> +
>> +    dev_pasid->dev = dev;
>> +    dev_pasid->pasid = pasid;
>> +    spin_lock_irqsave(&dmar_domain->lock, flags);
>> +    list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids);
>> +    spin_unlock_irqrestore(&dmar_domain->lock, flags);
> 
> ---> list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids);
> 
> dev_pasid is linked at later time, this leads to 
> domain->has_iotlb_device is not correctly set, which finally results 
> into a missing of device iotlb flush in iommu_flush_dev_iotlb()when it's 
> called.
> Check this call path:
> domain_attach_iommu()->domain_update_iommu_cap()->domain_update_iotlb()->domain->has_iotlb_device = has_iotlb_device; The ugly fixup is to call domain_update_iommu_cap() or domain_update_iotlb() here again before return.
> The similar issue is in intel_iommu_set_dev_pasid() and 
> intel_nested_attach_dev().

Yes, domain->has_iotlb_device must be updated whenever a domain is
attached to (or removed from) a RID or PASID. I would be grateful if you
could post some patches to fix the set_device_pasid and
nested_attach_dev paths.

I assume Yi can fix this series in the next version.

Best regards,
baolu

  reply	other threads:[~2023-12-14 13:33 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27  6:34 [PATCH 0/8] iommufd support pasid attach/replace Yi Liu
2023-11-27  6:34 ` [PATCH 1/8] iommu: Introduce a replace API for device pasid Yi Liu
2024-01-15 17:19   ` Jason Gunthorpe
2024-03-10 13:05     ` Yi Liu
2024-03-11  9:26       ` Tian, Kevin
2024-03-12  3:07         ` Yi Liu
2024-03-13  3:13           ` Baolu Lu
2024-03-13  8:11             ` Yi Liu
2024-03-18 16:52               ` Jason Gunthorpe
2024-03-19  7:29                 ` Yi Liu
2024-03-20 12:38                   ` Jason Gunthorpe
2024-03-21  6:16                     ` Yi Liu
2024-03-21 11:26                       ` Yi Liu
2024-03-21 12:20                         ` Jason Gunthorpe
2024-03-21 13:58                           ` Yi Liu
2023-11-27  6:34 ` [PATCH 2/8] iommufd: replace attach_fn with a structure Yi Liu
2023-11-27  6:34 ` [PATCH 3/8] iommufd: Support attach/replace hwpt per pasid Yi Liu
2024-01-15 17:24   ` Jason Gunthorpe
2024-01-16  1:18     ` Tian, Kevin
2024-01-16 12:57       ` Jason Gunthorpe
2024-01-17  4:17         ` Tian, Kevin
2024-01-17  8:24           ` Yi Liu
2024-01-17 12:56             ` Jason Gunthorpe
2024-01-18  9:28               ` Yi Liu
2024-01-18 13:38                 ` Jason Gunthorpe
2024-01-19 10:15                   ` Yi Liu
2023-11-27  6:34 ` [PATCH 4/8] iommufd/selftest: Add set_dev_pasid and remove_dev_pasid in mock iommu Yi Liu
2023-11-27  6:34 ` [PATCH 5/8] iommufd/selftest: Add a helper to get test device Yi Liu
2023-11-27  6:34 ` [PATCH 6/8] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2023-11-27  6:34 ` [PATCH 7/8] iommufd/selftest: Add coverage for iommufd " Yi Liu
2023-11-27  6:34 ` [PATCH 8/8] iommu/vt-d: Add set_dev_pasid callback for nested domain Yi Liu
2023-12-14  2:55   ` Yang, Weijiang
2023-12-14 13:33     ` Baolu Lu [this message]
2023-12-15  0:37       ` Yang, Weijiang
2024-01-15 17:22   ` Jason Gunthorpe
2024-01-17  8:20     ` Baolu Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e08dc77-82ce-40ce-8a0c-ac9016186c23@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=weijiang.yang@intel.com \
    --cc=xin.zeng@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    --cc=zhenzhong.duan@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.