Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices
> Are you willing to add your reviewed-by for Jim's v2 patch? I will > queue it for v5.6 if you both agree. Sure: Reviewed-by: Roland Dreier ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices
> Jim proposed another solution. > > https://lkml.org/lkml/2019/12/23/653 > > Does this work for you? Yes, that's OK for the cases I've seen too. All the NTB devices I've seen are PCI_CLASS_BRIDGE_OTHER with type 0 headers, so this patch would not break anything. And I think the idea of allowing DMAR bridge scope for all devices with PCI class bridge is logical - BIOS writers probably are going by PCI class rather than header type when assigning scope. - R. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices
> We saw more devices with the same mismatch quirk. So maintaining them in > a quirk table will make it more readable and maintainable. I guess I disagree about the maintainable part, given that this patch already regresses Broadwell NTB. I'm not even sure what the DMAR table says about NTB on my Skylake systems, exactly because the existing code means I did not have any problems. But we might need to add device 201Ch too. Maybe we don't need the mismatch check at all? Your patch sets the quirk if any possibly mismatching device is present in the system, so we'll ignore any scope mismatch on a system with, say, the 8086:2020 NVMe host in it. So could we just drop the check completely and not have a quirk to disable the check? - R. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2f0d, /* NTB devices */ > +quirk_dmar_scope_mismatch); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2020, /* NVME host */ > +quirk_dmar_scope_mismatch); what's the motivation for changing the logic into a quirk table, which has to be maintained with new device IDs? In particular this has the Haswell NTB ID 2F0Dh but already leaves out the Broadwell ID 6F0Dh. - R. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
