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

[Pranjal Shrivastava]

On Thu, Sep 10, 2026 at 07:45:01PM +0530, Vasant Hegde wrote:
> 
> 
> 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,
> >>>>
> >>>>

[...]

> >>>>
> >>>> 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?

[...]

> >>
> >> 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.

Ack. Sent out: https://lore.kernel.org/all/20260910142655.3281464-1-praan@xxxxxxxxxx/

Thanks,
Praan