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

[Pranjal Shrivastava]

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.

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

Thanks,
Praan