From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] iommu/vt-d: Fix missed device TLB cache tag
Date: Mon, 24 Jun 2024 13:12:51 -0300 [thread overview]
Message-ID: <20240624161251.GS791043@ziepe.ca> (raw)
In-Reply-To: <92033ab6-fb55-4206-9cb9-f81b5b6eede6@amd.com>
On Mon, Jun 24, 2024 at 07:56:03PM +0530, Vasant Hegde wrote:
> >> I remember of this discussion. May be we can provide API from IOMMU driver so
> >> that individual driver can enable/disable ATS (like iommu_dev_enable_feature()).
> >
> > But I have a feeling if we do that it should be done by re-attaching
> > the domain.
>
> Right. By default IOMMU will enable the ATS.. But if device driver decides to
> disable it (say due to HW bug), then we have to re-attach domain (in AMD case we
> have to update the DTE and flush the TLB).
SMMUv3 is the same, this is why I like doing it via the existing
re-attach domain interface since it already composes nicely with the
mechanisms the driver should have to update the DTE/etc.
> > Having an additional input to domain attach "inhibit ats", as a flag
> > would be all the support the driver would need to provide for the core
> > code to manage this with some kind of global policy.
>
> You mean for attach_dev() ?
Yes
> .. and what about PRI and PASID? Don't device driver needs similar interface ?
PRI is enabled by attaching a PRI capable domain
PASID should be assumed to be required if the device supports PASID.
Inhibiting PASID support would have to be done during domain
allocation. Soon the dev will always be available there and we could
do a policy like that via the dev structs? Not sure how much value
there is..
Jason
prev parent reply other threads:[~2024-06-24 16:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 1:53 [PATCH 1/1] iommu/vt-d: Fix missed device TLB cache tag Lu Baolu
2024-06-19 16:46 ` Jason Gunthorpe
2024-06-20 0:50 ` Baolu Lu
2024-06-20 3:04 ` Tian, Kevin
2024-06-20 3:13 ` Baolu Lu
2024-06-20 3:57 ` Tian, Kevin
2024-06-20 6:04 ` Baolu Lu
2024-06-20 5:54 ` Vasant Hegde
2024-06-20 6:27 ` Baolu Lu
2024-06-20 10:49 ` Vasant Hegde
2024-06-20 14:08 ` Jason Gunthorpe
2024-06-21 1:44 ` Baolu Lu
2024-06-21 12:58 ` Jason Gunthorpe
2024-06-24 14:26 ` Vasant Hegde
2024-06-24 16:12 ` Jason Gunthorpe [this message]
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=20240624161251.GS791043@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacek.lawrynowicz@linux.intel.com \
--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 \
/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