src/sys/dev/ntb, branch releng/12.4 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.4 2021-10-04T14:05:38Z ntb_hw_intel: fix xeon NTB gen3 bar disable logic 2021-10-04T14:05:38Z David Bright dab@FreeBSD.org 2021-09-27T13:18:46Z urn:sha1:50c20d90f97f7fe417ac111aebebe99aa8c943a6 In NTB gen3 driver, it was supposed to disable NTB bar access by default, but due to incorrect register access method, the bar disable logic does not work as expected. Those registers should be modified through NTB bar0 rather than PCI configuration space. Besides, we'd better to protect ourselves from a bad buddy node so ingress disable logic should be implemented together. Submitted by: Austin Zhang (austin.zhang@dell.com) Sponsored by: Dell EMC (cherry picked from commit e3cf7ebc1d36d068f1d1a83ea73ce2eed547e3cb) ntb_transport(4): Mark callouts MP-safe. 2021-08-24T02:34:58Z Alexander Motin mav@FreeBSD.org 2021-08-10T20:30:12Z urn:sha1:2d26a28153d21ed059b6f2fc854e3eaf9e85e6d7 The only thing around NTB using Giant lock is NewBus, and these callouts have nothing to do with it. MFC after: 2 weeks (cherry picked from commit c6902e7796bc78df011131a2b8b024faed884b8f) MFC r368563: 2020-12-19T04:21:15Z Ryan Libby rlibby@FreeBSD.org 2020-12-19T04:21:15Z urn:sha1:dfaa2c613d30ee3f89c0d25298c69c0486720e26 ntb: quiet gcc -Wreturn-type Reviewed by: cem, markj Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D27553 MFC r366969, r366973: 2020-11-22T18:54:14Z Mark Johnston markj@FreeBSD.org 2020-11-22T18:54:14Z urn:sha1:dc37ffd077dc721b12dfa817fdb9c7e3d8b4a2e3 ntb: Add Intel Xeon Gen3 support MFC r366968: 2020-10-30T14:38:17Z Mark Johnston markj@FreeBSD.org 2020-10-30T14:38:17Z urn:sha1:e40d2946647a989f2214c74048c53a781f712b78 ntb: Fix an assertion to permit >= 32 doorbells MFC r357920: Add support for Hygon NTB PCI device in ntb_hw_amd driver. 2020-02-21T04:29:50Z Alexander Motin mav@FreeBSD.org 2020-02-21T04:29:50Z urn:sha1:34a83f0b04097ce603c46153b8fb22064852e29f MFC r355165: Make DMAR allow Intel NTB device to access its own BAR0. 2019-12-04T15:14:14Z Alexander Motin mav@FreeBSD.org 2019-12-04T15:14:14Z urn:sha1:b68476653ba00aab5c13596832e00ec68376e6be 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 r355163: Make the code slightly more compact. 2019-12-04T15:12:09Z Alexander Motin mav@FreeBSD.org 2019-12-04T15:12:09Z urn:sha1:2e5e878513afd42526bd3751ef66201d3c4dfcfa There should be no functional change. MFC r355074: Report XLAT0 register for completeness. 2019-12-04T15:11:42Z Alexander Motin mav@FreeBSD.org 2019-12-04T15:11:42Z urn:sha1:f03b2b212d3585e50632cc8e4672da8833092e98 MFC r354702: 2019-11-28T00:40:42Z Alexander Motin mav@FreeBSD.org 2019-11-28T00:40:42Z urn:sha1:f447184e2df72d55fd4a1c65d44a89aec8c8c086 Make ntb(4) send bus_get_dma_tag() requests to parent buses passing real bus' child pointers instead of grandchilds. DMAR does not like requests from devices not parented directly by PCI.