| Message ID | 20210621165230.3.I7accc008905590bb2b46f40f91a4aeda5b378007@changeid |
|---|---|
| State | New |
| Headers | show |
| Series | iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC | expand |
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. 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? greg k-h
Hi, On Thu, Jun 24, 2021 at 6:38 AM Greg KH <gregkh@linuxfoundation.org> 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
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 275204646c68..8d81f0fb3e50 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1572,8 +1572,10 @@ static void set_pcie_untrusted(struct pci_dev *dev) * untrusted as well. */ parent = pci_upstream_bridge(dev); - if (parent && (parent->untrusted || parent->external_facing)) + if (parent && (parent->untrusted || parent->external_facing)) { dev->untrusted = true; + dev->dev.force_strict_iommu = true; + } } /**
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. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/pci/probe.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)