[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6e88db76-6903-cb7b-b608-811a97986592@linux.intel.com>
Date: Tue, 11 Jul 2023 10:43:43 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Tina Zhang <tina.zhang@...el.com>
Cc: baolu.lu@...ux.intel.com, Kevin Tian <kevin.tian@...el.com>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Michael Shavit <mshavit@...gle.com>, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 5/6] iommu: Support mm PASID 1:1 with sva domain
On 2023/7/11 1:28, Jason Gunthorpe wrote:
>> @@ -88,31 +98,41 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
>> goto out_unlock;
>> }
>>
>> - if (domain) {
>> - domain->users++;
>> - goto out;
>> + if (unlikely(domain)) {
>> + /* Re-attach the device to the same domain? */
>> + if (domain == sva_domain) {
>> + goto out;
>> + } else {
>> + /* Didn't get detached from the previous domain? */
>> + ret = -EBUSY;
>> + goto out_unlock;
>> + }
>> }
> And if we do all of this we should just get rid of the horrible
> iommu_get_domain_for_dev_pasid() entirely.
At the core level, we have no idea about whether an sva domain allocated
for one device is compatible with another device. Hence, we should loop
the sva domains in the list and if the attach interface feeds back
-EINVAL's (not compatible), we should allocate a new domain for the
attached device and put it in the list if the new attachment is
successful.
Perhaps I'm too worried?
Best regards,
baolu
Powered by blists - more mailing lists