On Sat, Feb 8, 2020 at 2:30 PM Lu Baolu <baolu...@linux.intel.com> wrote: > > The devices under segment 1 are fake devices produced by > > intel-nvme-remap mentioned here https://lkml.org/lkml/2020/2/5/139 > > Has this series been accepted?
Sadly not - we didn't find any consensus on the right approach, and further conversation is hindered by the questionable hardware design and lack of further communication from Intel in explaining it. It's one of the exceptional cases where we carry a significant non-upstream kernel change, because unfortunately most of the current day consumer PCs we work with have this BIOS option on by default and hence unmodified Linux can't access the storage devices. On the offchance that you have some energy to bubble this up inside Intel please let me know and we will talk more... :) That said, this thread was indeed only opened since we thought we had found a more general issue that would potentially affect other cases. The issue described does seem to highlight a possible imperfection in code flow, although it may also be reasonable to say that (without crazy downstream patches at play) if intel_iommu_add_device() fails then we have bigger problems to face anyway... > Will this help here? https://www.spinics.net/lists/iommu/msg41300.html Yes! Very useful info and a real improvement. We'll follow the same approach here. That does solve the problem we were facing, although we needed one more fixup which I've sent separately for your consideration: iommu/vt-d: consider real PCI device when checking if mapping is needed Thanks! Daniel _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
