Linux IOMMU Development
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: baolu.lu@linux.intel.com, "Deucher,
	Alexander" <Alexander.Deucher@amd.com>,
	"Hegde, Vasant" <Vasant.Hegde@amd.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@amd.com>,
	"Huang2, Wei" <Wei.Huang2@amd.com>,
	"jsnitsel@redhat.com" <jsnitsel@redhat.com>,
	"Kuehling, Felix" <Felix.Kuehling@amd.com>
Subject: Re: [PATCH v3 1/5] iommu/amd: Remove iommu_v2 module
Date: Fri, 22 Sep 2023 20:13:02 +0800	[thread overview]
Message-ID: <a4770035-9f1a-3bff-2ff2-d6b9c81e2c0b@linux.intel.com> (raw)
In-Reply-To: <20230922115927.GI13733@nvidia.com>

On 2023/9/22 19:59, Jason Gunthorpe wrote:
> On Fri, Sep 22, 2023 at 10:23:26AM +0800, Baolu Lu wrote:
> 
>> 1) PCI device supports ATS but*no*  PASID
>>     In this case, ATS only means a TLB cache in the device, and it does
>>     not make much sense to cache the 1:1 mappings in the device. Even
>>     worse, the ATS translation requests could probably cause I/O
>>     congestion in corner cases. Therefore, the best choice is probably to
>>     disable ATS on the device.
> Nope. We have important use cases where ATS must always be on. 🙁

Oh, I didn't know that. Thank you for letting me know.

> 
> You might make this argument if ACS is also non-isolating though..
> 
> Regardless I think we need to get into a position where the iommu core
> is deciding if PRI or ATS is enabled for a device, not the iommu
> driver.

Agreed. I ever had a series to achieve this and it may be time to
revisit them.

One additional concern is how the core knows whether ATS should be
enabled. In my previous design, the IOMMU core turns on ATS by default
if the device is capable of it, but the driver could enable/disable it
from its driver probe() callback.

Does it make sense?

Best regards,
baolu

  reply	other threads:[~2023-09-22 12:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-21  9:31 [PATCH v3 0/5] iommu/amd: SVA Support (part 2) - deprecate iommu_v2 module Vasant Hegde
2023-09-21  9:31 ` [PATCH v3 1/5] iommu/amd: Remove " Vasant Hegde
2023-09-21 14:05   ` Deucher, Alexander
2023-09-21 14:14     ` Jason Gunthorpe
2023-09-21 15:15       ` Deucher, Alexander
2023-09-21 16:31         ` Jason Gunthorpe
2023-09-22  2:23           ` Baolu Lu
2023-09-22  8:52             ` Vasant Hegde
2023-09-22 12:00               ` Jason Gunthorpe
2023-09-25 15:11                 ` Vasant Hegde
2023-09-25 15:57                   ` Jason Gunthorpe
2023-09-25 16:31                   ` Deucher, Alexander
2023-09-25 16:37                     ` Jason Gunthorpe
2023-09-22 11:59             ` Jason Gunthorpe
2023-09-22 12:13               ` Baolu Lu [this message]
2023-09-22 12:18                 ` Jason Gunthorpe
2023-09-22 12:42                   ` Baolu Lu
2023-09-22 12:43                     ` Jason Gunthorpe
2023-09-25  9:04                   ` joro
2023-09-25 15:40                     ` Vasant Hegde
2023-09-28 14:52                     ` Deucher, Alexander
2023-10-05 11:29                       ` Vasant Hegde
2023-10-06 15:19                         ` Deucher, Alexander
2023-09-22 18:08                 ` Deucher, Alexander
2023-09-22 18:15           ` Deucher, Alexander
2023-09-22  6:45         ` Vasant Hegde
2023-09-22 18:13           ` Deucher, Alexander
2023-09-25 15:30             ` Vasant Hegde
2023-09-21  9:31 ` [PATCH v3 2/5] iommu/amd: Remove PPR support Vasant Hegde
2023-09-21  9:31 ` [PATCH v3 3/5] iommu/amd: Remove amd_iommu_device_info() Vasant Hegde
2023-09-21  9:31 ` [PATCH v3 4/5] iommu/amd: Remove unused EXPORT_SYMBOLS Vasant Hegde
2023-09-21  9:31 ` [PATCH v3 5/5] Revert "iommu: Fix false ownership failure on AMD systems with PASID activated" Vasant Hegde
2023-10-02  6:32 ` [PATCH v3 0/5] iommu/amd: SVA Support (part 2) - deprecate iommu_v2 module Joerg Roedel
2023-10-05 11:30   ` Vasant Hegde

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=a4770035-9f1a-3bff-2ff2-d6b9c81e2c0b@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=Vasant.Hegde@amd.com \
    --cc=Wei.Huang2@amd.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.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