From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FAKE_REPLY_C,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 476A8C43215 for ; Wed, 20 Nov 2019 19:49:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 17B782071F for ; Wed, 20 Nov 2019 19:49:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574279392; bh=8OdhdfUvBh8yeItPx5lvDqJRDQbjk4jNjuLGV67HFng=; h=Date:From:To:Cc:Subject:In-Reply-To:List-ID:From; b=wuPuA7eV5yB7236OOkNwceV9LZYCpWPgPbWfCAuM8GsBlZJi6qXRcjql5/mpmBdGu /BQJ5GUCGmN9q+a+yBMlZu3zH/EhycToEVJ7nl33riVfScPi5wstfzSCkGRqk5sMTn lZLIw44AxcUZIMmnpI5f4hhUUHtwqUsYtdPvHZtk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727480AbfKTTtv (ORCPT ); Wed, 20 Nov 2019 14:49:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:37130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbfKTTtu (ORCPT ); Wed, 20 Nov 2019 14:49:50 -0500 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 983292068F; Wed, 20 Nov 2019 19:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574279389; bh=8OdhdfUvBh8yeItPx5lvDqJRDQbjk4jNjuLGV67HFng=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=GbZyyAeiPOGuUe8N9Fv82aD0Pxho+dCO/gqZASt0YMaHyTmsnepyhPWHi4F6E3Phf jUAFSXAIM8P2hprpRslh8ToPol8KmKVsY2+p5MB2UQYj0IOa6HKnCafT5bzsdT8K7l IksCj4JrRGuMlqVJRFKXNX+7eQdIEjpVSf5J3B1A= Date: Wed, 20 Nov 2019 13:49:48 -0600 From: Bjorn Helgaas To: Logan Gunthorpe Cc: Dmitry Safonov <0x7f454c46@gmail.com>, James Sewart , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Dmitry Safonov , linux-pci@vger.kernel.org, Alex Williamson Subject: Re: [PATCH] Ensure pci transactions coming from PLX NTB are handled when IOMMU is turned on Message-ID: <20191120194948.GA117003@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 20, 2019 at 12:30:48PM -0700, Logan Gunthorpe wrote: > On 2019-11-20 10:48 a.m., Dmitry Safonov wrote: > > On 11/5/19 12:17 PM, James Sewart wrote: > >> > >>> On 24 Oct 2019, at 13:52, James Sewart wrote: > >>> > >>> The PLX PEX NTB forwards DMA transactions using Requester ID's that don't exist as > >>> PCI devices. The devfn for a transaction is used as an index into a lookup table > >>> storing the origin of a transaction on the other side of the bridge. > >>> > >>> This patch aliases all possible devfn's to the NTB device so that any transaction > >>> coming in is governed by the mappings for the NTB. > >>> > >>> Signed-Off-By: James Sewart > >>> --- > >>> drivers/pci/quirks.c | 22 ++++++++++++++++++++++ > >>> 1 file changed, 22 insertions(+) > >>> > >>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > >>> index 320255e5e8f8..647f546e427f 100644 > >>> --- a/drivers/pci/quirks.c > >>> +++ b/drivers/pci/quirks.c > >>> @@ -5315,6 +5315,28 @@ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ > >>> SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ > >>> SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ > >>> > >>> +/* > >>> + * PLX NTB uses devfn proxy IDs to move TLPs between NT endpoints. These IDs > >>> + * are used to forward responses to the originator on the other side of the > >>> + * NTB. Alias all possible IDs to the NTB to permit access when the IOMMU is > >>> + * turned on. > >>> + */ > >>> +static void quirk_PLX_NTB_dma_alias(struct pci_dev *pdev) > >>> +{ > >>> + if (!pdev->dma_alias_mask) > >>> + pdev->dma_alias_mask = kcalloc(BITS_TO_LONGS(U8_MAX), > >>> + sizeof(long), GFP_KERNEL); > >>> + if (!pdev->dma_alias_mask) { > >>> + dev_warn(&pdev->dev, "Unable to allocate DMA alias mask\n"); > >>> + return; > >>> + } > >>> + > >>> + // PLX NTB may use all 256 devfns > >>> + memset(pdev->dma_alias_mask, U8_MAX, (U8_MAX+1)/BITS_PER_BYTE); > > I think it would be better to create a pci_add_dma_alias_range() > function instead of directly accessing dma_alias_mask. We could then use > that function to clean up quirk_switchtec_ntb_dma_alias() which is > essentially doing the same thing. Great idea! Bjorn