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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 907F6C433ED for ; Thu, 6 May 2021 10:49:22 +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 37D696103E for ; Thu, 6 May 2021 10:49:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37D696103E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=mifZx8psv4HqL+UTJTjDXehZtUo+2mYH/W1JjAZaj3M=; b=M+jtZurVKEyYdB3tPnKbaYJLf fcKcgVQrfJIqeEVJMk0yo1tZlxng3ooGMGIAC9utV+nHILdwWVR5w4TZ15N76btuifMFlz/PMPsR2 RuHPOAHeOoF53T+SGku0ceX4BfOXcw+QcnlC8J0eigIQlefZh7/qu6zkSG61dIhCm1kLXFCHLqKYZ +1bnvQqB5JIVuohOGmkpzusIF9wcZO+rmO6LSfjGyouSEmj10+CHk+wS6mY1CZ4afxSQieruP1L9V 7hk4+kNiLiCM9pwwbAS45g3+TNr9cjxTCIluYS3cQLSKhgjNQsuaYdksxE7dTM4TwTuMTU11+OKyJ NAQruFoCw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lebWt-0041ia-8h; Thu, 06 May 2021 10:46:51 +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 1lebWr-0041hP-AX for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 10:46:49 +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=R4s5YQ+sOFetO2VSVW09THGiqe0OKroxeY5zVb+Ua10=; b=GzkbeLI9M2b0TJBZDs3YKergUT qbaQGcAUcfgLykFMwTZgJ5sa4Y5QhmAiEOEXd5I1jRNVetyD/Q7/ykuOegWhX/HG19CbpovTELC9l CTk2+ZBQxRFL6A2MSmZU5mZehwaR8lVcGO1SZOfn280tsX85Fun/94XTGGHII6pNzzZEEoHuItMLN bK11Ok6UnsuGpcJ85d33rwUuewLEI8mINXIXxURL+CpiaHj+mhzLkjnZY0szLgsdDnIDiSbSGHxex EBt+4xPCY946gv5cDagUcxENFuEPD++RtpWX5XtZn/tFhVewtwsoBOwFictutFyhZMMDbNqmfQHY/ xbDl2iiQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lebWo-005xnK-Mn for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 10:46:48 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id DBAC861132; Thu, 6 May 2021 10:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620298006; bh=3rAAXCIsngjgHIt0hbp1ycnMKqvEavK7JpgsKAgUF/o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=khVKLGhjqzMYbjF2ZXAooF4G/o30evlkHc/XJ8Aq3VlPopZsJ1pWZmKvqKk+MqTZN V75GkqLOtO+gczjNLR+WpkNl4bw5tujUCp+5Bibw0p2BXogdva6KdGZBcPiA39jngR trJPRB+kXwcV9dA8rchOiIzlOU0qQOw8vT9qhvgDrkehVR+14rELAMd4cxLKYT0UkZ ds4ykMPG4Pr+5zSMP0w7pjGNVRRlZHjkJSCCEHBZF8rTCoxHrYOx+XGy7iexXlFrTl qIw+qhTK5qIAe/LJmNYkU9+b7dx4AdGTOPjACYrnxjuMMHmbPvPkaMfh8X/drNxCFT R14Ku1TR03+RA== Date: Thu, 6 May 2021 11:46:41 +0100 From: Will Deacon To: Mark Rutland 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: <20210506104640.GA15324@willie-the-truck> References: <20210506095034.15246-1-will@kernel.org> <20210506095034.15246-3-will@kernel.org> <20210506102009.GA32366@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210506102009.GA32366@C02TD0UTHF1T.local> 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-20210506_034646_799851_90ED06FC X-CRM114-Status: GOOD ( 18.79 ) 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: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? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel