All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Kevin Tian <kevin.tian@intel.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d: Disable PCI ATS in legacy passthrough mode
Date: Thu, 30 Nov 2023 13:44:19 +0800	[thread overview]
Message-ID: <8186755c-fe80-424c-9b50-06ea213b3b17@linux.intel.com> (raw)
In-Reply-To: <20231129201324.GL1312390@ziepe.ca>

On 2023/11/30 4:13, Jason Gunthorpe wrote:
> On Tue, Nov 14, 2023 at 09:10:35AM +0800, Lu Baolu wrote:
>> When IOMMU hardware operates in legacy mode, the TT field of the context
>> entry determines the translation type, with three supported types (Section
>> 9.3 Context Entry):
>>
>> - DMA translation without device TLB support
>> - DMA translation with device TLB support
>> - Passthrough mode with translated and translation requests blocked
>>
>> Device TLB support is absent when hardware is configured in passthrough
>> mode.
>>
>> Disable the PCI ATS feature when IOMMU is configured for passthrough
>> translation type in legacy (non-scalable) mode.
> Oh.. That is the same horrible outcome that ARM has 🙁
> 
> The issue is what to do if the RID translation is in identity but a
> PASID is attached that should be using ATS - eg do you completely
> loose SVA support if the RID is set to the optimized identity mode?

This fix only affects the non-scalable mode that doesn't support PASID
  features.

> I vote no. We should make the drivers aware that they should not use
> ATS on their RIDs instead 🙁

Intel VT-d hardware does not supported ATS in non-scalable mode when
translation is set to passthrough mode. Historically, the Intel IOMMU
driver has never enabled the ATS feature in this configuration.

Commit 0faa19a1515f changed this behavior by accident, potentially
leading to incorrect hardware configuration. This patch fixes the issue
by reverting to the previous behavior. Otherwise, it leads to hardware
configuration errors and potential DMA malfunction, as all translated
DMA requests would be blocked by the IOMMU.

Going forward, I agree that device drivers should have the ability to
access and potentially control the ATS status. I have a upcoming series
that will enable device drivers or user-space to manage the ATS as we
have discussed in other threads before.

Best regards,
baolu

  reply	other threads:[~2023-11-30  5:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14  1:10 [PATCH 1/1] iommu/vt-d: Support enforce_cache_coherency only for empty domains Lu Baolu
2023-11-14  1:10 ` [PATCH 1/1] iommu/vt-d: Omit devTLB invalidation requests when TES=0 Lu Baolu
2023-11-14  3:14   ` Tian, Kevin
2023-11-14  3:13     ` Baolu Lu
2023-11-14  4:45       ` Tian, Kevin
2023-11-14  4:54         ` Baolu Lu
2023-11-14  5:31           ` Tian, Kevin
2023-11-29 20:10   ` Jason Gunthorpe
2023-11-30  4:06     ` Baolu Lu
2023-11-30 12:15       ` Jason Gunthorpe
2023-11-14  1:10 ` [PATCH 1/1] iommu/vt-d: Disable PCI ATS in legacy passthrough mode Lu Baolu
2023-11-14  3:14   ` Tian, Kevin
2023-11-16  7:35   ` Baolu Lu
2023-11-16  8:24     ` Tian, Kevin
2023-11-17  1:09       ` Baolu Lu
2023-11-17  2:22         ` Tian, Kevin
2023-11-29 20:13   ` Jason Gunthorpe
2023-11-30  5:44     ` Baolu Lu [this message]
2023-11-30 16:18       ` Jason Gunthorpe
2023-11-14  1:10 ` [PATCH 1/1] iommu/vt-d: Make context clearing consistent with context mapping Lu Baolu
2023-11-14  3:20   ` Tian, Kevin
2023-11-14  3:22     ` Baolu Lu
2023-11-14  4:46       ` Tian, Kevin
2023-11-14  3:16 ` [PATCH 1/1] iommu/vt-d: Support enforce_cache_coherency only for empty domains Tian, Kevin
2023-11-29 20:08 ` Jason Gunthorpe
2023-11-30  3:48   ` Baolu Lu

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=8186755c-fe80-424c-9b50-06ea213b3b17@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=robin.murphy@arm.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 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.