On 28.02.2022 19:19, Alex Olson wrote: > FYI, with this patch, I was seeing msix_read() and msix_write() being called > during the driver's self-test on physical address 0xfbc01800, corresponding to > the beginning of the PBA (lspci excerpt below): > > > 02:00.0 System peripheral: Intel Corporation Xeon Processor D Family > QuickData Technology Register DMA Channel 0 > ... > Region 0: Memory at fbc06000 (64-bit, non-prefetchable) [size=8K] > ... > Capabilities: [ac] MSI-X: Enable+ Count=1 Masked- > Vector table: BAR=0 offset=00001000 > PBA: BAR=0 offset=00001800 > ... > Kernel modules: ioatdma > > > > The functions involved on the Linux kernel side are: > > ioat_probe() > -> ioat3_dma_self_test() > -> ioat_dma_self_test() > -> ioat_free_chan_resources() > -> ioat_reset_hw() > > drivers/dma/ioat/dma.c: ioat_reset_hw() > ... > ioat_dma->msixpba = readq(ioat_dma->reg_base + 0x1800); > ... > writeq(ioat_dma->msixpba, ioat_dma->reg_base + 0x1800);
Wow, a clear and apparently intentional violation of the PCI spec. There was a workaround for a reset issue introduced by commit 8a52b9ff1154, which was then revised by c997e30e7f65 to take the present shape. However, both commits claim this only affects certain Atoms, albeit the latter less explicitly by having "CB3.3" in the subject. Yet you're seeing this on a Xeon D ... Jan
