[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a95e8a10-6240-41db-b234-d9f29386694c@linux.intel.com>
Date: Tue, 15 Oct 2024 10:52:19 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: baolu.lu@...ux.intel.com, iommu@...ts.linux.dev,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>, Kevin Tian <kevin.tian@...el.com>,
Yi Liu <yi.l.liu@...el.com>, Vasant Hegde <vasant.hegde@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] iommu/vt-d: Enhance compatibility check for paging
domain attach
On 2024/10/15 3:24, Jason Gunthorpe wrote:
> On Mon, Oct 14, 2024 at 09:25:03AM +0800, Baolu Lu wrote:
>>>> + if (domain->type & __IOMMU_DOMAIN_PAGING) {
>>> It looks like this entire function is already never called for
>>> anything but paging?
>>>
>>> The only three callers are:
>>>
>>> .default_domain_ops = &(const struct iommu_domain_ops) {
>>> .attach_dev = intel_iommu_attach_device,
>>> .set_dev_pasid = intel_iommu_set_dev_pasid,
>>>
>>> and
>>>
>>> static const struct iommu_domain_ops intel_nested_domain_ops = {
>>> .attach_dev = intel_nested_attach_dev,
>>>
>>> And none of those cases can be anything except a paging domain by
>>> definition.
>> A nested domain is not a paging domain. It represents a user-space page
>> table that nested on a parent paging domain. Perhaps I overlooked
>> anything?
> It only calls it on the s2_parent which is always a paging domain?
>
> ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev);
Yea, you are right. I overlooked that part. I'll remove the 'if'
statement and utilize a WARN_ON() function instead.
And also, I will rename this function with a meaningful name,some like
paging_domain_is_compatible()?
Thanks,
baolu
Powered by blists - more mailing lists