On Mon, 2020-04-13 at 10:48 +0800, Lu Baolu wrote: > Hi Daniel, > > On 2020/4/13 10:25, Daniel Drake wrote: > > On Fri, Apr 10, 2020 at 9:22 AM Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx> wrote: > > > This is caused by the fragile private domain implementation. We are in > > > process of removing it by enhancing the iommu subsystem with per-group > > > default domain. > > > > > > https://www.spinics.net/lists/iommu/msg42976.html > > > > > > So ultimately VMD subdevices should have their own per-device iommu data > > > and support per-device dma ops. > > > > Interesting. There's also this patchset you posted: > > [PATCH 00/19] [PULL REQUEST] iommu/vt-d: patches for v5.7 > > https://lists.linuxfoundation.org/pipermail/iommu/2020-April/042967.html > > (to be pushed out to 5.8) > > Both are trying to solve a same problem. > > I have sync'ed with Joerg. This patch set will be replaced with Joerg's > proposal due to a race concern between domain switching and driver > binding. I will rebase all vt-d patches in this set on top of Joerg's > change. > > Best regards, > baolu > Thanks Baolu. I'll pick this back up on top of the for-5.8 changes. > > In there you have: > > > iommu/vt-d: Don't force 32bit devices to uses DMA domain > > which seems to clash with the approach being explored in this thread. > > > > And: > > > iommu/vt-d: Apply per-device dma_ops > > This effectively solves the trip point that caused me to open these > > discussions, where intel_map_page() -> iommu_need_mapping() would > > incorrectly determine that a intel-iommu DMA mapping was needed for a > > PCI subdevice running in identity mode. After this patch, a PCI > > subdevice in identity mode uses the default system dma_ops and > > completely avoids intel-iommu. > > > > So that solves the issues I was looking at. Jon, you might want to > > check if the problems you see are likewise solved for you by these > > patches. > > > > I didn't try Joerg's iommu group rework yet as it conflicts with those > > patches above. > > > > Daniel > >
