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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 E1EF2C433E2 for ; Wed, 2 Sep 2020 17:23:18 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AEE4C20684 for ; Wed, 2 Sep 2020 17:23:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fvQCjxXn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEE4C20684 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=adtl9zTgCvK/mkk00Y4+LD2Zgz9lcCChYt93/dZiH14=; b=fvQCjxXn/PPWQH5Pqyx7IjZfn /4x2H5mxDKFOy4OZrfqu6/hNmU/91G7JqnRIzuUqOfQIciN3Uc1Y6ByrfdT3QumAxmJtIHwmptP2n wW407lZGjwUy10x3jFR6qRnvDRbkdpk89m8XfLkCedfzaDcaYUcA5i0Tbbi9hyH4T/5av7MGG5X8k NVq1rr3oEYSD61XJbelyrh/TEsClj7M+FRwuXYzpq0hgKKjhYkK94JoxcZAoFtDoRH8lY8bY7Sxh8 8lxLiV/gvgu+9BH++X34c2nWeaOT1Jz/8USwRZXIVC1o5v5ZgYayDc2w19ZhVCM+kANpoBJQcM+Li IiyhNaMKQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDWSS-0000sf-Cl; Wed, 02 Sep 2020 17:22:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDWSQ-0000s5-66 for linux-arm-kernel@lists.infradead.org; Wed, 02 Sep 2020 17:22:02 +0000 Received: from gaia (unknown [46.69.195.48]) (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 04B2B20684; Wed, 2 Sep 2020 17:21:59 +0000 (UTC) Date: Wed, 2 Sep 2020 18:21:57 +0100 From: Catalin Marinas To: Lorenzo Pieralisi Subject: Re: [PATCH] arm64: Enable PCI write-combine resources under sysfs Message-ID: <20200902172156.GD16673@gaia> References: <20200831151827.pumm2p54fyj7fz5s@amazon.com> <20200902113207.GA27676@e121166-lin.cambridge.arm.com> <20200902142922.xc4x6m33unkzewuh@amazon.com> <20200902164702.GA30611@e121166-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200902164702.GA30611@e121166-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200902_132202_340141_32FA519C X-CRM114-Status: GOOD ( 31.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pci@vger.kernel.org, Bjorn Helgaas , benh@kernel.crashing.org, will@kernel.org, linux-arm-kernel@lists.infradead.org, Clint Sbisa Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 02, 2020 at 05:47:02PM +0100, Lorenzo Pieralisi wrote: > On Wed, Sep 02, 2020 at 02:29:22PM +0000, Clint Sbisa wrote: > > On Wed, Sep 02, 2020 at 12:32:07PM +0100, Lorenzo Pieralisi wrote: > > > On Mon, Aug 31, 2020 at 03:18:27PM +0000, Clint Sbisa wrote: > > > > arm64 supports write-combine PCI mappings, so the appropriate define > > > > has been added which will expose write-combine mappings under sysfs > > > > for prefetchable PCI resources. > > > > > > > > Signed-off-by: Clint Sbisa > > > > --- > > > > arch/arm64/include/asm/pci.h | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h > > > > index 70b323cf8300..b33ca260e3c9 100644 > > > > --- a/arch/arm64/include/asm/pci.h > > > > +++ b/arch/arm64/include/asm/pci.h > > > > @@ -17,6 +17,7 @@ > > > > #define pcibios_assign_all_busses() \ > > > > (pci_has_flag(PCI_REASSIGN_ALL_BUS)) > > > > > > > > +#define arch_can_pci_mmap_wc() 1 > > > > > > I am not comfortable with this blanket enable. Some existing drivers, > > > eg: > > > > > > drivers/infiniband/hw/mlx5 > > > > > > use this macro to detect WC capability which again, it is x86 specific, > > > on arm64 it means nothing and can have consequences on the driver > > > operations. > > > > If that driver is fixed to check what it actually wants to check, would that > > address your concern about the blanket enable? I don't see any other references > > to this in kernel drivers and I think the documentation at > > `filesystems/sysfs-pci.rst` outlines it pretty explicitly: > > > > Platforms which support write-combining maps of PCI resources must define > > arch_can_pci_mmap_wc() which shall evaluate to non-zero at runtime when > > write-combining is permitted. > > That's exactly the problem. I am asking you: what does "write-combining > maps of PCI resources" mean ? > > I understand we do want weak ordering for prefetchable BAR mappings > but my worry is that by exposing the resources as WC to user space > we are giving user space the impression that those mappings mirror > x86 WC mappings behaviour that is not true on ARM64. Would Device_GRE be close to the x86 WC better? It won't allow unaligned accesses and that can be problematic for the user. OTOH, it doesn't speculate reads, so it's safer from the hardware perspective. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel