From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>
Cc: baolu.lu@linux.intel.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 10:23:26 +0800 [thread overview]
Message-ID: <19c7c139-b002-384f-5766-b87a8013029e@linux.intel.com> (raw)
In-Reply-To: <20230921163154.GO13733@nvidia.com>
On 9/22/23 12:31 AM, Jason Gunthorpe wrote:
> On Thu, Sep 21, 2023 at 03:15:42PM +0000, Deucher, Alexander wrote:
>>>> Does this patch or the following patches make any functional changes
>>>> for devices? E.g., devices which supported ATS would have been put
>>>> into an identity mapping mode previously Is that still retained?
>>>
>>> Huh? Why would we ever want to do that?
>>>
>>> Policy for the default domain belongs in the iommu subsystem except in
>>> extreme cases, the AMD driver should not be doing random things like forcing
>>> identity for ATS capable PCI devices.
>>
>> I'm just concerned about regressions in random devices due to a
>> change in policy in the IOMMU driver. Previously the IOMMU driver
>> would put ATS compatible devices into 1:1 mode. Also some of the
>> earlier integrated GPUs require 1:1 mapping for display from system
>> memory due to hardware limitations. There were also a lot of sbios
>> bugs in the carrizo/raven timeframe because windows didn't enable
>> the IOMMU so lots of OEMs had bogus IOMMU ACPI tables which didn't
>> cause problems when 1:1 mode was used.
>
> That is a fair concern.
>
> But we need to root those out and fix them as narrow quirks. We don't
> want a driver to have blanket ATS == identity configuration, it will
> harm other legitimate applications.
I am interested in the policy that an IOMMU driver would apply to ATS
when the default domain is configured in PASSTHROUGH mode.
I have considered the following cases:
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.
2) PCI device supports ATS and PASID
In this case, ATS is required for PRI, so we should enable it even if
the default domain has been configured to PASSTHROUGH mode.
Is this the right way to think about it?
Best regards,
baolu
next prev parent reply other threads:[~2023-09-22 2:26 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 [this message]
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
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=19c7c139-b002-384f-5766-b87a8013029e@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