Linux IOMMU Development
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>
Subject: Re: [PATCH v2 12/12] iommu/vt-d: Add set_dev_pasid callback for nested domain
Date: Wed, 8 May 2024 21:26:47 +0800	[thread overview]
Message-ID: <5efdd36d-2759-4f71-92f6-4b639fc9dbc8@intel.com> (raw)
In-Reply-To: <20240508122556.GF4650@nvidia.com>

On 2024/5/8 20:25, Jason Gunthorpe wrote:
> On Wed, May 08, 2024 at 02:10:05PM +0800, Yi Liu wrote:
>> On 2024/5/7 23:18, Jason Gunthorpe wrote:
>>> On Tue, May 07, 2024 at 10:28:34AM +0800, Yi Liu wrote:
>>>>>> We still need something to do before we can safely remove this check.
>>>>>> All the domain allocation interfaces should eventually have the device
>>>>>> pointer as the input, and all domain attributions could be initialized
>>>>>> during domain allocation. In the attach paths, it should return -EINVAL
>>>>>> directly if the domain is not compatible with the iommu for the device.
>>>>>
>>>>> Yes, and this is already true for PASID.
>>>>
>>>> I'm not quite get why it is already true for PASID. I think Baolu's remark
>>>> is general to domains attached to either RID or PASID.
>>>>
>>>>> I feel we could reasonably insist that domanis used with PASID are
>>>>> allocated with a non-NULL dev.
>>>>
>>>> Any special reason for this disclaim?
>>>
>>> If it makes the driver easier, why not?
>>
>> yep.
>>
>>> PASID is special since PASID is barely used, we could insist that
>>> new PASID users also use the new domian_alloc API.
>>
>> Ok. I have one doubt on how to make it in iommufd core. Shall the iommufd
>> core call ops->domain_alloc_paging() directly or still call
>> ops->domain_alloc_user() while ops->domain_alloc_user() flows into the
>> paging domain allocation with non-null dev?
> 
> I mostly figured we'd need a new iommu_domain_alloc_dev() sort of
> thing? VFIO should be changed over too.

Would this new iommu-domain_alloc_dev() have flags and user_data input?
As below code snippet, the existing iommufd core uses domain_alloc_user
op to allocate the s2 domain (paging domain), and will fall back to
iommu_domain_alloc() only if the domain_alloc_user op does not exist. The
typical reason is to use domain_alloc_user op is to allocate a paging
domain with NESTED_PARENT flag. I suppose the new iommu_domain_alloc_dev()
shall allow allocating s2 domain with NESTED_PARENT as well. right?


struct iommufd_hwpt_paging *
iommufd_hwpt_paging_alloc(struct iommufd_ctx *ictx, struct iommufd_ioas *ioas,
			  struct iommufd_device *idev, u32 flags,
			  bool immediate_attach,
			  const struct iommu_user_data *user_data)
{

	...
	if (ops->domain_alloc_user) {
		hwpt->domain = ops->domain_alloc_user(idev->dev, flags, NULL,
						      user_data);
		if (IS_ERR(hwpt->domain)) {
			rc = PTR_ERR(hwpt->domain);
			hwpt->domain = NULL;
			goto out_abort;
		}
		hwpt->domain->owner = ops;
	} else {
		hwpt->domain = iommu_domain_alloc(idev->dev->bus);
		if (!hwpt->domain) {
			rc = -ENOMEM;
			goto out_abort;
		}
	}
	...
}

-- 
Regards,
Yi Liu

  reply	other threads:[~2024-05-08 13:23 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12  8:15 [PATCH v2 00/12] iommufd support pasid attach/replace Yi Liu
2024-04-12  8:15 ` [PATCH v2 01/12] iommu: Pass old domain to set_dev_pasid op Yi Liu
2024-04-15  5:32   ` Baolu Lu
2024-04-15 11:54     ` Jason Gunthorpe
2024-04-16  2:07       ` Baolu Lu
2024-04-16 17:47         ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 02/12] iommu: Introduce a replace API for device pasid Yi Liu
2024-04-16  3:01   ` Duan, Zhenzhong
2024-04-16  9:18     ` Yi Liu
2024-04-17  8:44   ` Tian, Kevin
2024-04-17 12:17     ` Jason Gunthorpe
2024-04-18  0:08       ` Tian, Kevin
2024-04-29 13:55   ` Jason Gunthorpe
2024-04-30  5:00     ` Yi Liu
2024-04-30 12:26       ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 03/12] iommufd: replace attach_fn with a structure Yi Liu
2024-04-12  8:15 ` [PATCH v2 04/12] iommufd: Support attach/replace hwpt per pasid Yi Liu
2024-04-29 13:56   ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 05/12] iommu: Allow iommu driver to populate the max_pasids Yi Liu
2024-04-15  5:41   ` Baolu Lu
2024-04-17  8:49     ` Tian, Kevin
2024-04-20  5:45       ` Yi Liu
2024-04-22 11:52         ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 06/12] iommufd/selftest: Add set_dev_pasid and remove_dev_pasid in mock iommu Yi Liu
2024-04-12  8:15 ` [PATCH v2 07/12] iommufd/selftest: Add a helper to get test device Yi Liu
2024-04-12  8:15 ` [PATCH v2 08/12] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2024-04-12  8:15 ` [PATCH v2 09/12] iommufd/selftest: Add coverage for iommufd " Yi Liu
2024-04-12  8:15 ` [PATCH v2 10/12] iommu/vt-d: Return if no dev_pasid is found in domain Yi Liu
2024-04-15  6:04   ` Baolu Lu
2024-04-16  9:21     ` Yi Liu
2024-04-17  2:30       ` Baolu Lu
2024-04-17  3:48         ` Yi Liu
2024-04-17  9:03   ` Tian, Kevin
2024-04-17  9:36     ` Yi Liu
2024-04-12  8:15 ` [PATCH v2 11/12] iommu/vt-d: Make intel_iommu_set_dev_pasid() to handle domain replacement Yi Liu
2024-04-17  9:19   ` Tian, Kevin
2024-04-17  9:35     ` Yi Liu
2024-04-17 12:19       ` Jason Gunthorpe
2024-04-12  8:15 ` [PATCH v2 12/12] iommu/vt-d: Add set_dev_pasid callback for nested domain Yi Liu
2024-04-17  9:25   ` Tian, Kevin
2024-04-30  9:19     ` Yi Liu
2024-05-06  7:42       ` Baolu Lu
2024-05-06 13:36         ` Jason Gunthorpe
2024-05-07  2:28           ` Yi Liu
2024-05-07 15:18             ` Jason Gunthorpe
2024-05-08  6:10               ` Yi Liu
2024-05-08 12:25                 ` Jason Gunthorpe
2024-05-08 13:26                   ` Yi Liu [this message]
2024-05-08 14:11                     ` Jason Gunthorpe
2024-05-09 14:22                       ` Liu, Yi L

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=5efdd36d-2759-4f71-92f6-4b639fc9dbc8@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox