Linux IOMMU Development
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Tina Zhang <tina.zhang@intel.com>
Cc: baolu.lu@linux.intel.com, Kevin Tian <kevin.tian@intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Michael Shavit <mshavit@google.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 5/6] iommu: Support mm PASID 1:1 with sva domain
Date: Tue, 11 Jul 2023 10:43:43 +0800	[thread overview]
Message-ID: <6e88db76-6903-cb7b-b608-811a97986592@linux.intel.com> (raw)
In-Reply-To: <ZKw/xS7wOoRvNfnH@ziepe.ca>

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

  parent reply	other threads:[~2023-07-11  2:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-07  1:34 [RFC PATCH 0/6] Share sva domain with all devices bound to a mm Tina Zhang
2023-07-07  1:34 ` [RFC PATCH 1/6] iommu: Add two pasid helper functions Tina Zhang
2023-07-07  1:34 ` [RFC PATCH 2/6] iommu: Call helper functions to get/set assigned pasid value Tina Zhang
2023-07-07  1:34 ` [RFC PATCH 3/6] iommu: Introduce struct iommu_mm_data Tina Zhang
2023-07-07  1:34 ` [RFC PATCH 4/6] mm: Add iommu_mm field to mm_struct Tina Zhang
2023-07-07  1:34 ` [RFC PATCH 5/6] iommu: Support mm PASID 1:1 with sva domain Tina Zhang
2023-07-10 17:28   ` Jason Gunthorpe
2023-07-11  1:42     ` Zhang, Tina
2023-07-11  2:43     ` Baolu Lu [this message]
2023-07-11 14:18       ` Jason Gunthorpe
2023-07-17  8:47   ` Yanfei Xu
2023-07-07  1:34 ` [RFC PATCH 6/6] mm: Deprecate pasid field Tina Zhang
2023-07-10 17:29   ` Jason Gunthorpe
2023-07-11  1:46     ` Zhang, Tina

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=6e88db76-6903-cb7b-b608-811a97986592@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mshavit@google.com \
    --cc=tina.zhang@intel.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox