Hi,
On 1/7/20 9:30 AM, Jerry Snitselaar wrote:
On Tue Jan 07 20, Lu Baolu wrote:
Hi Jerry,
On 1/7/20 1:05 AM, Jerry Snitselaar wrote:
On Wed Jan 01 20, Roland Dreier via iommu wrote:
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.
If the check is removed what happens for cases where there is an actual
problem in the dmar table? I just worked an issue with some Intel
people where a purley system had an rmrr entry pointing to a bridge as
the endpoint device instead of the raid module sitting behind it.
The latest solution was here. https://lkml.org/lkml/2020/1/5/103, does
this work for you?
Best regards,
baolu
Hi Baolu,
They resolved it by updating the rmrr entry in the dmar table to add
the extra path needed for it to point at the raid module. Looking
at the code though I imagine without the firmware update they would
still have the problem because IIRC it was a combo of an endpoint
scope type, and a pci bridge header so that first check would fail
as it did before. My worry was if the suggestion is to remove the
check completely, a case like that wouldn't report anything wrong.
Yes, agreed.
Jim's latest patch I think solves the issue for what he was seeing
and the NTB case.
Jerry and Roland,
Are you willing to add your reviewed-by for Jim's v2 patch? I will
queue it for v5.6 if you both agree.
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
