public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Kevin Tian <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
	Vasant Hegde <vasant.hegde@amd.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/7] iommu/vt-d: Enhance compatibility check for paging domain attach
Date: Fri, 11 Oct 2024 13:27:03 -0300	[thread overview]
Message-ID: <20241011162703.GL762027@ziepe.ca> (raw)
In-Reply-To: <20241011042722.73930-4-baolu.lu@linux.intel.com>

On Fri, Oct 11, 2024 at 12:27:18PM +0800, Lu Baolu wrote:

> @@ -1623,27 +1623,15 @@ static int domain_context_mapping_one(struct dmar_domain *domain,
>  
>  	copied_context_tear_down(iommu, context, bus, devfn);
>  	context_clear_entry(context);
> -
>  	context_set_domain_id(context, did);
>  
> -	/*
> -	 * Skip top levels of page tables for iommu which has
> -	 * less agaw than default. Unnecessary for PT mode.
> -	 */
> -	for (agaw = domain->agaw; agaw > iommu->agaw; agaw--) {
> -		ret = -ENOMEM;
> -		pgd = phys_to_virt(dma_pte_addr(pgd));
> -		if (!dma_pte_present(pgd))
> -			goto out_unlock;
> -	}

Yikes, this is nasty racy stuff, glad to see it go

But should the agaw stuff be in its own patch?

> @@ -3506,27 +3483,26 @@ int prepare_domain_attach_device(struct iommu_domain *domain,
>  	if (domain->dirty_ops && !ssads_supported(iommu))
>  		return -EINVAL;
>  
> -	/* check if this iommu agaw is sufficient for max mapped address */
> -	addr_width = agaw_to_width(iommu->agaw);
> -	if (addr_width > cap_mgaw(iommu->cap))
> -		addr_width = cap_mgaw(iommu->cap);
> -
> -	if (dmar_domain->max_addr > (1LL << addr_width))
> +	if (dmar_domain->iommu_coherency !=
> +			iommu_paging_structure_coherency(iommu))
>  		return -EINVAL;
> -	dmar_domain->gaw = addr_width;
> -
> -	/*
> -	 * Knock out extra levels of page tables if necessary
> -	 */
> -	while (iommu->agaw < dmar_domain->agaw) {
> -		struct dma_pte *pte;
> -
> -		pte = dmar_domain->pgd;
> -		if (dma_pte_present(pte)) {
> -			dmar_domain->pgd = phys_to_virt(dma_pte_addr(pte));
> -			iommu_free_page(pte);
> -		}
> -		dmar_domain->agaw--;
> +
> +	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.

So this if should go away, or be turned into a WARN_ON.

Jason

  reply	other threads:[~2024-10-11 16:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11  4:27 [PATCH 0/7] iommu/vt-d: Add domain_alloc_paging support Lu Baolu
2024-10-11  4:27 ` [PATCH 1/7] " Lu Baolu
2024-10-11 13:22   ` Jason Gunthorpe
2024-10-11 16:33     ` Jason Gunthorpe
2024-10-14  0:53     ` Baolu Lu
2024-10-14 19:23       ` Jason Gunthorpe
2024-10-11  4:27 ` [PATCH 2/7] iommu/vt-d: Remove unused domain_alloc callback Lu Baolu
2024-10-11 16:17   ` Jason Gunthorpe
2024-10-11  4:27 ` [PATCH 3/7] iommu/vt-d: Enhance compatibility check for paging domain attach Lu Baolu
2024-10-11 16:27   ` Jason Gunthorpe [this message]
2024-10-14  1:25     ` Baolu Lu
2024-10-14 19:24       ` Jason Gunthorpe
2024-10-15  2:52         ` Baolu Lu
2024-10-15 12:48           ` Jason Gunthorpe
2024-10-16  1:46             ` Baolu Lu
2024-10-11  4:27 ` [PATCH 4/7] iommu/vt-d: Remove domain_update_iommu_cap() Lu Baolu
2024-10-11 16:30   ` Jason Gunthorpe
2024-10-11  4:27 ` [PATCH 5/7] iommu/vt-d: Remove domain_update_iommu_superpage() Lu Baolu
2024-10-11 16:30   ` Jason Gunthorpe
2024-10-11  4:27 ` [PATCH 6/7] iommu/vt-d: Refactor first_level_by_default() Lu Baolu
2024-10-11 16:31   ` Jason Gunthorpe
2024-10-11  4:27 ` [PATCH 7/7] iommu/vt-d: Refine intel_iommu_domain_alloc_user() Lu Baolu
2024-10-11 11:32   ` Jason Gunthorpe
2024-10-11 16:31   ` Jason Gunthorpe

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=20241011162703.GL762027@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@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