Hi, On Thu, Jun 24, 2021 at 6:38 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 21, 2021 at 04:52:45PM -0700, Douglas Anderson wrote: > > At the moment the generic IOMMU framework reaches into the PCIe device > > to check the "untrusted" state and uses this information to figure out > > if it should be running the IOMMU in strict or non-strict mode. Let's > > instead set the new boolean in "struct device" to indicate when we > > want forced strictness. > > > > NOTE: we still continue to set the "untrusted" bit in PCIe since that > > apparently is used for more than just IOMMU strictness. It probably > > makes sense for a later patchset to clarify all of the other needs we > > have for "untrusted" PCIe devices (perhaps add more booleans into the > > "struct device") so we can fully eliminate the need for the IOMMU > > framework to reach into a PCIe device. > > It feels like the iommu code should not be messing with pci devices at > all, please don't do this. I think it's generally agreed that having the IOMMU code reach into the PCIe code is pretty non-ideal, but that's not something that my patch series added. The IOMMU code already has special cases to reach into PCIe devices to decide strictness. I was actually trying to reduce the amount of it. > Why does this matter? Why wouldn't a pci device use "strict" iommu at > all times? What happens if it does not? Why are PCI devices special? This is something pre-existing in Linux. In my patch series I was trying to make PCI devices less special and take some of the concepts from there and expand them, but in a cleaner way. It sounds like in my v2 I should steer away from this and leave the existing PCI hacks alone. -Doug
