From: Jason Gunthorpe <jgg@nvidia.com>
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>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete devices
Date: Tue, 28 Feb 2023 08:23:17 -0400 [thread overview]
Message-ID: <Y/3yNaQD5Pkvf61k@nvidia.com> (raw)
In-Reply-To: <20230228023341.973671-1-baolu.lu@linux.intel.com>
On Tue, Feb 28, 2023 at 10:33:41AM +0800, Lu Baolu wrote:
> In normal processing of PCIe ATS requests, the IOMMU performs address
> translation and returns the device a physical memory address which
> will be stored in that device's IOTLB. The device may subsequently
> issue Translated DMA request containing physical memory address. The
> IOMMU only checks that the device was allowed to issue such requests
> and does not attempt to validate the physical address.
>
> The Intel IOMMU implementation only allows PCIe ATS on several SOC-
> integrated devices which are opt-in’ed through the ACPI tables to
> prevent any compromised device from accessing arbitrary physical
> memory.
>
> Add a kernel option intel_iommu=relax_ats to allow users to have an
> opt-in to allow turning on ATS at as wish, especially for CSP-owned
> vertical devices. In any case, risky devices are not allowed to use
> ATS.
Why is this an intel specific option? all it does is effectively
disable untrusted? Why not a global option? All iommu with ATS will
need this?
Also, why doesn't a "CSP" set their ACPI to make the devices they want
to use ATS with trusted instead of this?
Jason
next prev parent reply other threads:[~2023-02-28 12:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 2:33 [PATCH 1/1] iommu/vt-d: Add opt-in for ATS support on discrete devices Lu Baolu
2023-02-28 12:23 ` Jason Gunthorpe [this message]
2023-03-01 4:22 ` Baolu Lu
2023-03-01 14:04 ` Jason Gunthorpe
2023-03-01 17:15 ` Robin Murphy
2023-03-01 17:42 ` Jason Gunthorpe
2023-03-01 18:19 ` Robin Murphy
2023-03-02 2:30 ` Baolu Lu
2023-03-03 8:19 ` Tian, Kevin
2023-03-03 9:51 ` Baolu Lu
2023-03-03 13:18 ` Jason Gunthorpe
2023-03-07 5:20 ` Tian, Kevin
2023-03-02 1:56 ` 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=Y/3yNaQD5Pkvf61k@nvidia.com \
--to=jgg@nvidia.com \
--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=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.