[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] vpci/msix: fix PBA accesses
- To: Alex Olson <this.is.a0lson@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 1 Mar 2022 08:43:06 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w5DX0udg4woY/xz8lzpN0tu8Ytb/rhBWFqUXG783oug=; b=aytmH14XCewHVyZnE5wvnbRDzWfurqgCQEZeCVvu1vLugg+ilkBvam5oAWAx9qG2pxFN5vhxAacOPLxgWhHEg/+fzsgEAFSHUFLYR98tLTnCevt4gUJL6iG7qib8dyBs9xYGNmqGKDF4zWmmB5tfziUiE+pkuGxgSNANfVku9o0rofaoApfOFo3UCtUpPTvQtqErkY1hdeXFKAtVjdfRSFz8EhPg/JRNvmki46FfwbX53tit/u34lBygUV7T07GGm0KDWnEK1BVUFKoUiJbGfPylk/H4wH2iVR8LpMtiJu1DCnKBPrxRh45vSIBiPjpN2g8VxUBcyiPALVX43aTJng==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DZUMm/tST9bd9eWlDck8VsycV/xbT6PPKlJvWvUPRZuKY2QPteJMeR9Pu15uperTJ+lxt1F4cafxgjEd9489RCDo9o3d91PKD1onc14WWVRshLF9XoCvvmrCwqrUx470R4QoRh2o6KQoN3jj2idzAXQYMLXqCz7nnaKYV7gVhBGAp9aqUCtaWUIFbrqHemqt+xtYaWZz4nRTTgIC6nL4zfBabHWrZkiDQe4Z/umtSvOW3+2qBN9opm8eQ5SQl9/3/YSwXR9hTktXYRLynIOhkdZgKA95J8Xw/0M3npbp94/movyPy26QNubCVfS6TT3EbvC5st/3gQTxT3wYvZB4ew==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 01 Mar 2022 07:43:16 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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
|
