Re: [PATCH v2 1/2] iommu/amd: Add PerfOpt IOMMU performance optimization support

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/28/26 07:08, Jason Gunthorpe wrote:
> On Fri, Sep 25, 2026 at 07:33:08PM -0500, Mario Limonciello wrote:
>>
>>
>> On 9/25/26 5:39 PM, Jason Gunthorpe wrote:
>>> On Fri, Sep 25, 2026 at 08:11:41AM -0500, Mario Limonciello wrote:
>>>>
>>>>
>>>> On 9/25/26 07:28, Jason Gunthorpe wrote:
>>>>> On Fri, Sep 25, 2026 at 09:20:02AM +0200, Joerg Roedel wrote:
>>>>>> On Thu, Sep 24, 2026 at 07:50:18PM -0300, Jason Gunthorpe wrote:
>>>>>>> Why does the GPU driver have to request this? Why can't the iommu
>>>>>>> driver know that this is a special device that can use this magic fast
>>>>>>> path and then auto set it when identity is asked for?
>>>>>>
>>>>>> This is a layering violation either way. Either the IOMMU driver needs to poke
>>>>>> into device details and their relations or the device driver needs to poke into
>>>>>> IOMMU details.
>>>>>
>>>>> There are no device details, this is just a module option in the gpu
>>>>> driver.
>>>>
>>>> Well the GPU driver has knowledge whether it's a GPU inside of an APU to
>>>> decide if it's valid.  That information is part of the discovery table
>>>> setup.
>>>
>>> Where was that in patch 2?
>>
>> amdgpu_device_use_perfopt()
> 
> Ah, sneaky, that looks like it just decodes from a a giant list of PCI IDs

Actually; no.  amdgpu has migrated away from PCI IDs and probes based on 
the "ATI vendor" + "display class" instead.  As part of the probe 
sequence there is something called an IP discovery table pull from the 
platform that identifies all IP blocks in the hardware.

This IP discovery table will indicate graphics IP and that is mapped to 
relevant driver code.  So for example GC 11.5.1 is what you find in a 
Strix Halo APU.  If a future APU had exactly the same graphics IP but a 
different display IP it would still be GC 11.5.1.

This design was implemented about 4 years ago, and all SoCs (APU, dGPU 
and accelerator) since then use it.
>   
>>> The right way for this to work is to quirk it through the iommu driver
>>> so it can choose the fast mode, and not involve the GPU driver at
>>> all. Like we've done for every other GPU weirdness. And AMD should be
>>> making this work better by providing ACPI support so the iommu driver
>>> can understand how it should work without inspecting PCI IDs.
>>
>> There is a heuristic that Vasant added recently that we detect APU from the
>> IOMMU driver.  We might be able to use that for now.
>>
>> I'll take a look at what an incremental patch looks like on top of
>> iommu/next that I think reworks all these paths the way you want.  I should
>> be able to post something next week.
> 
> ACPI is the right answer to these kinds of problems.
> 
> Jason

I'll discuss this with architects for the future programs.

For now as promissed I've worked out a patch [1] that keeps it all in 
iommu/amd per your suggestions.  It is using the existing APU heuristic.

https://lore.kernel.org/linux-iommu/20260928045050.955165-1-superm1@kernel.org/ 
[1]