Re: [PATCH v3 2/5] iommu/amd: Fix DTE clearing and rename iommu_ignore_device()

[Vasant Hegde <vasant.hegde@amd.com>]

On 9/10/2026 7:17 PM, Pranjal Shrivastava wrote:
> On Thu, Sep 10, 2026 at 05:25:25PM +0530, Vasant Hegde wrote:
>>
>>
>> On 9/4/2026 7:55 PM, Jason Gunthorpe wrote:
>>> On Fri, Sep 04, 2026 at 03:43:01PM +0530, Vasant Hegde wrote:
>>>> Jason,
>>>>
>>>>
>>>> On 8/28/2026 5:23 PM, Jason Gunthorpe wrote:
>>>>> On Fri, Aug 28, 2026 at 10:46:48AM +0530, Vasant Hegde wrote:
>>>>>>> Having the driver boot up with all DTEs programmed to identity (eg
>>>>>>> 0'd) and then try to fix them to blocking after the iommu probes
>>>>>>> devices is security backwards.
>>>>>>
>>>>>> During boot, it only sets dte.v bit.
>>>>>
>>>>> First it clears it to fully 0, what does 0 do in HW?
>>>>
>>>> IF DTE is fully zero, then all requests are blocked for that devid.
>>>>
>>>>>
>>>>> It doesn't make sense that you'd pass over the DTEs after
>>>>> probing if the original 0'd DTE was actually blocking?
>>>>
>>>> During boot, it sets certain default values includ dte.v. It doesn't
>>>> clear everything.
>>>
>>> ?? It starts out with a 0 DTE table? There is no inherited DTE table
>>> except for kdump.
>>>
>>>> May be we should just remove ignore_device() completely? as
>>>>   - normal boot, its not yet configured, so no DMA is allowed
>>>>   - kdump boot, old DTE is still valid and let it continue?
>>>
>>> Yes, that makes alot more sense to me.
>>
>> Ack. @Pranjal, Can you fixup and send v4?
>>
> 
> Ack. I'll remove ignore_device entirely and drop patch 3 for v4.

Thanks.

> 
>>>
>>> But this comment is also wrong:
>>
>> Yeah. One of the cleanup patch missed to update below comment.
>>
>>>
>>>         /*
>>>          * Order is important here to make sure any unity map requirements are
>>>          * fulfilled. The unity mappings are created and written to the device
>>>          * table during the iommu_init_pci() call.
>>>          *
>>>          * After that we call init_device_table_dma() to make sure any
>>>          * uninitialized DTE will block DMA, and in the end we flush the caches
>>>          * of all IOMMUs to make sure the changes to the device table are
>>>          * active.
>>>          */
>>>         for_each_pci_segment(pci_seg)
>>>                 init_device_table_dma(pci_seg);
>>>
>>> The DTE starts out with blocking because it starts out as 0. This
>>> isn't making the DTE blocking, it is doing something else. And it is
>>> very suspicious and racey looking to me.
>>
>> IIRC there were some requirement to keep V bit ON. Otherwise I don't see why we
>> should set and flush the dte here. Let me dig the details.
>>
> 
> Should I also update the comment in this series? (It seems less relevant
> to the ATS stuff)

I'd say lets do that as separate patch. For now lets get this series finalized.

-Vasant