]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Make DMAR allow Intel NTB device to access its own BAR0.
authormav <mav@FreeBSD.org>
Thu, 28 Nov 2019 02:40:12 +0000 (02:40 +0000)
committermav <mav@FreeBSD.org>
Thu, 28 Nov 2019 02:40:12 +0000 (02:40 +0000)
commit1efe697292981c452a1e95d811e6d5fb8e4ec0e3
treef3fd543c8336e7f7c89e865f0dd534772c1e5ac5
parente20ff198081b3fd813ba20b6b44a35fdc7a8866e
Make DMAR allow Intel NTB device to access its own BAR0.

I have no good explanation why it happens, but I found that in B2B mode
at least Xeon v4 NTB leaks accesses to its configuration memory at BAR0
originated from the link side to its host side.  DMAR predictably blocks
those, making access to remote scratchpad registers in B2B mode impossible.

This change creates identity mapping in DMAR covering the BAR0 addresses,
making the NTB work fine with DMAR enabled.  It seems like allowing single
4KB range at 32KB offset may be enough, but I don't see a reason to be so
specific.

MFC after: 1 week
Sponsored by: iXsystems, Inc.
sys/dev/ntb/ntb_hw/ntb_hw_intel.c