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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 9831EC433ED for ; Thu, 6 May 2021 11:03:01 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 4488561164 for ; Thu, 6 May 2021 11:03:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4488561164 Authentication-Results: mail.kernel.org; dmarc=fail (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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc: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=FRSf7EGYkvRQ6KxnqWo8E8ESFY84GDcBDD5QxhBjpmA=; b=QvPBCAvTPnv78H8T8KdyloI8N WUAuafw2HNy00fsnusurV5LRqSB/yttC+f0MRCUlydCD6isvG/LV/LZi6G/Hi2zmUhK7dFOhlVwEx I6+tbyD5Nky1b1kP2uIw3cUboc0iKPdYXLG7bXeOcmtRGm72eWeQh20JrS16ROZ2Dj8UJp0bUw/za je5nwULycS1AMBD9qsvER8pqsSnBLkGoQEiyoF0sbEUZ/e2aTHt7tmnGmQKq9ijU9GYFM1OrXNt3v BS/I3dcu0I+e7AGjCiAm0LOrIUyf4RIHyL9Olm2ipDSAJw46PINtTp0QBczbgvhJoTSVgt4jXcP02 m+ckELkoQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lebkJ-0044KI-O0; Thu, 06 May 2021 11:00:43 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lebjx-0044Eo-ME for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 11:00:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=V/9qawIjkstaIkMkttV/yfqcksvYeTTu/r37pP4q8tg=; b=DJ68T+EPyCes3LXXMqQhYUgP6R HNLJ5klNAeRQtbFnjgvZWwPP7wdTOvNL+Py67sFOIt0TQSmbmDTzhm/oGL18obr02cwxIdc0s7LP7 31mgRjWbnh1ZPc5GXBcd/w8Sd0Wyfi0LYNehCUmJw9QJOl8A59ndav17PDU1KhHKeL5/1Uz3jhT7j UR55eGTt7Vrf+cvt012LOzOMgv+TTRP7DBUA9BWSu38Sea+RCS3/dfgj0AwYdEbeRUgbBhEPUMs2C mc7KQOu7CrGKhQWDrKBR8jfIG7fDM9RZ5ukHqc3ZaXqlYYZCq2dA9jHL9Z9Wo15IDQUIKQDtsRqKn lG9SXOSw==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lebju-005y9R-UK for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 11:00:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 50984101E; Thu, 6 May 2021 04:00:13 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.31.158]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AAC633F73B; Thu, 6 May 2021 04:00:11 -0700 (PDT) Date: Thu, 6 May 2021 12:00:08 +0100 From: Mark Rutland To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Christoph Hellwig , Catalin Marinas , Ard Biesheuvel , Lorenzo Pieralisi Subject: Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC Message-ID: <20210506110008.GC32366@C02TD0UTHF1T.local> References: <20210506095034.15246-1-will@kernel.org> <20210506095034.15246-3-will@kernel.org> <20210506102009.GA32366@C02TD0UTHF1T.local> <20210506104640.GA15324@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210506104640.GA15324@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_040019_064816_97699660 X-CRM114-Status: GOOD ( 23.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, May 06, 2021 at 11:46:41AM +0100, Will Deacon wrote: > On Thu, May 06, 2021 at 11:20:45AM +0100, Mark Rutland wrote: > > On Thu, May 06, 2021 at 10:50:33AM +0100, Will Deacon wrote: > > > The only user we have of Normal Write-Through memory is in the ACPI code > > > when mapping memory regions advertised as EFI_MEMORY_WT. Since most (all?) > > > CPUs treat write-through as non-cacheable under the hood, don't bother > > > with the extra memory type here and just treat EFI_MEMORY_WT the same way > > > as EFI_MEMORY_WC by mapping it to the Normal-NC memory type instead. > > > > The UEFI spec explicitly defines EFI_MEMORY_WT as Normal Outer-WT > > Inner-WT (and even explicitly specifies the MAIR.Attr value). > > I wonder if they just did that because the names match :( > > > In the UEFI 2.9 spec, see section 2.3.6.1 "Memory types", Table 2-5 > > "Map: EFI Cacheability Attributes to AArch64 Memory Types". > > > > The UEFI 2.9 spec can be found at: > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf > > > > Given that is specified explicitly, and given that we don't know how > > future CPUs will treat this equivalently, I don't think this change is > > architecturally sound and I don't think there's wiggle-room to read the > > spec as permitting this. > > At the same time, allocating a MAIR for this memory type just because the > UEFI spec permits some theoretical future firmware to use it on some > theoretical CPU design is pretty farcical in my opinion. Looking through > current TRMs I've not been able to find a CPU that doesn't just emit > Normal-NC for this memory type. > > How about I add a pr_warn() in this case, so that we can revisit it in the > unlikely event that it ever comes up as an issue? If we also could avoid mapping EFI_MEMORY_WT to anything, that'd be nicer, but just the warning is probably good enough, yes. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel