All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: question about iommu_need_mapping
Date: Thu, 20 Feb 2020 10:49:39 +0800	[thread overview]
Message-ID: <af5a148e-76bc-4aa4-dd1c-b04a5ffc56b1@linux.intel.com> (raw)
In-Reply-To: <20200219235516.zl44y7ydgqqja6x5@cantor>

Hi Jerry,

On 2020/2/20 7:55, Jerry Snitselaar wrote:
> Is it possible for a device to end up with dev->archdata.iommu == NULL
> on iommu_need_mapping in the following instance:
> 
> 1. iommu_group has dma domain for default
> 2. device gets private identity domain in intel_iommu_add_device
> 3. iommu_need_mapping gets called with that device.
> 4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via 
> unlink_domain_info.
> 5. request_default_domain_for_dev exits after checking that 
> group->default_domain
>     exists, and group->default_domain->type is dma.
> 6. iommu_request_dma_domain_for_dev returns 0 from 
> request_default_domain_for_dev
>     and a private dma domain isn't created for the device.
> 

Yes. It's possible.

> The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d:
> Allow devices with RMRRs to use identity domain"), because it changed
> which domain the group and devices were using, but it seems like it is
> still a possibility with the code. Baolu, you mentioned possibly
> removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle
> 32bit device with identity default domain") makes it sound like the
> domain switch is required.

It's more "nice to have" than "required" if the iommu driver doesn't
disable swiotlb explicitly. The device access of system memory higher
than the device's addressing capability could go through the bounced
buffer implemented in swiotlb.

Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: question about iommu_need_mapping
Date: Thu, 20 Feb 2020 10:49:39 +0800	[thread overview]
Message-ID: <af5a148e-76bc-4aa4-dd1c-b04a5ffc56b1@linux.intel.com> (raw)
In-Reply-To: <20200219235516.zl44y7ydgqqja6x5@cantor>

Hi Jerry,

On 2020/2/20 7:55, Jerry Snitselaar wrote:
> Is it possible for a device to end up with dev->archdata.iommu == NULL
> on iommu_need_mapping in the following instance:
> 
> 1. iommu_group has dma domain for default
> 2. device gets private identity domain in intel_iommu_add_device
> 3. iommu_need_mapping gets called with that device.
> 4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via 
> unlink_domain_info.
> 5. request_default_domain_for_dev exits after checking that 
> group->default_domain
>     exists, and group->default_domain->type is dma.
> 6. iommu_request_dma_domain_for_dev returns 0 from 
> request_default_domain_for_dev
>     and a private dma domain isn't created for the device.
> 

Yes. It's possible.

> The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d:
> Allow devices with RMRRs to use identity domain"), because it changed
> which domain the group and devices were using, but it seems like it is
> still a possibility with the code. Baolu, you mentioned possibly
> removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle
> 32bit device with identity default domain") makes it sound like the
> domain switch is required.

It's more "nice to have" than "required" if the iommu driver doesn't
disable swiotlb explicitly. The device access of system memory higher
than the device's addressing capability could go through the bounced
buffer implemented in swiotlb.

Best regards,
baolu

  reply	other threads:[~2020-02-20  2:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 23:55 question about iommu_need_mapping Jerry Snitselaar
2020-02-19 23:55 ` Jerry Snitselaar
2020-02-20  2:49 ` Lu Baolu [this message]
2020-02-20  2:49   ` Lu Baolu
2020-02-20 16:24   ` Jerry Snitselaar
2020-02-20 16:24     ` Jerry Snitselaar
2020-02-20 17:32     ` Jerry Snitselaar
2020-02-20 17:32       ` Jerry Snitselaar

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=af5a148e-76bc-4aa4-dd1c-b04a5ffc56b1@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.