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=-14.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 21460C433B4 for ; Thu, 6 May 2021 10:18:21 +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 7D88B61177 for ; Thu, 6 May 2021 10:18:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D88B61177 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=U32Rj4ukSF9N0GL638PmFEIYCXfR5GCw0NfIxDFgiHc=; b=A3CJTnOeAYEcktQU4yKe/ZqrG VS1yUszuXdxu0HFMIt54T7abxcWZlpGCtClgOgjcsaAhUvqET/vY/u2e9LUlG5vXd0dcOD0YsV3MW Jyw7EA0GQTpnsKQ+k41nalR8t/u48R07y94WcJEwlhrQtNBUQ8YG0+8edqfhyAoBm3/XDZlntnJum pWm7JZE3pHn7omOHHVgbI99pzwmKfBZ30jhzV8g+RWnMlMpkw8Vv/uXxjHI8xe36AN3fnRamjPRwP NBBXsTdYBHWMTPo1bYMR5ETQJ9uFDLc+8Mc3/UMT838OBXEgnOZNuKE5Q/9jekpl9HV6EKGTT9xYD kK2hXcTeQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1leb2H-003w6i-3B; Thu, 06 May 2021 10:15:13 +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 1leb2E-003w6V-DN for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 10:15:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=VaQLxwyiixDpYUohTczcvuFB5gN6hardNWvlaiGNBdM=; b=H6IHCOOLxxDIW4E9/PlWm4VQHi GFJX5qQjsfgpfx9UbPYH/oM2tU+sofdOGevrZPN10X8OZfSJIp4Srik51LLQFXcuvWN6Svh6vx6Zu leizgkGrURj2QuWL4pTvLBjS3D8Sp70LyGfCHPzl0sRK+LysxSqoQOTzcnwCDwJph34ipFmgjL/97 b2gE0mLtLWTmT437zM+t1gl481mTYT5tmgArE3YhOHpU0tJuQMmYVE/tj2oKSSozqPkOcpXFHwFPw vKoaptyUWughTMzUOTm9pjK5EmLnVz68FJuN6Yh0n3p9p9u4Q2CWUBU8efSvf8evIkkjoBzwcdcty /e4bbF8Q==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1leb2B-005wWZ-S1 for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 10:15:09 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5D75961378 for ; Thu, 6 May 2021 10:15:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620296107; bh=Qi02cFwt2tH2TprZ1unHEekFGbAY94k4Zab6hseoTMo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u7NvpughORuEPsHIE/Ceo9DDS1OvSm40sTQIWBMizes5flHNxDb4Md4p2Nnkbe9nj VBUTXlQRKJb64/yI3Il5bNTi2Yq6liT9foWlQRUpS6TwbG4hlDUCfjE0i6v7W2zSFR vqLyboHD+W7EyL5hHCS4Dj/eZxPAHR2A+5YEaXkNEqpXH5rY8NYe39zlBKru1iKy1d x0e5og8EOxP8Dqt5IQ8XS/y9Am5rPMYB6f0sU+SmfHd9RCzlN2loiWG2iUbFL1qkfJ o49l84FEW0WLm1mDhws9xzPYlSILWH0DgvzdBBR5iWuWrEGnqFjSwEwtf50NQF2NcJ j/Q0Q76sZmIng== Received: by mail-ot1-f53.google.com with SMTP id d3-20020a9d29030000b029027e8019067fso4385556otb.13 for ; Thu, 06 May 2021 03:15:07 -0700 (PDT) X-Gm-Message-State: AOAM530onfcQ6PK2JTGMof5j9PQ3T+YqFTkcKmq55vntnsDkbIexCavY 9lEz84ixjK5vuZXLa3hcScxtmfDEDHxMHxncvP8= X-Google-Smtp-Source: ABdhPJxStZeOkovDtlsh5OuZdvXeZ18OdiAFuDfVN2a2+aHLXS1H93jDkIqTiuvaa2/230LV7AmRt/80fXPGY4Nh2Xw= X-Received: by 2002:a9d:12e:: with SMTP id 43mr3032873otu.90.1620296106594; Thu, 06 May 2021 03:15:06 -0700 (PDT) MIME-Version: 1.0 References: <20210506095034.15246-1-will@kernel.org> <20210506095034.15246-3-will@kernel.org> In-Reply-To: <20210506095034.15246-3-will@kernel.org> From: Ard Biesheuvel Date: Thu, 6 May 2021 12:14:55 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC To: Will Deacon Cc: Linux ARM , Christoph Hellwig , Catalin Marinas , Lorenzo Pieralisi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_031507_987344_FD6E4388 X-CRM114-Status: GOOD ( 24.47 ) 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, 6 May 2021 at 11:50, 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. > > Cc: Ard Biesheuvel > Cc: Lorenzo Pieralisi > Cc: Christoph Hellwig > Signed-off-by: Will Deacon I don't have any objections to this change per se, but I will point out that the UEFI spec describes the MAIR encodings, paragraph 2.3.6.1 (in revision 2.8B). However, the paragraph in question provides no context whatsoever, and so it is not clear whether it is normative, and whether it applies to the boot time firmware only or to the OS as well. So in summary, given that EFI_MEMORY_WT (which I have never seen being used on ARM) should behave as expected when using the same MAIR attributes as EFI_MEMORY_WC, with only a theoretical performance impact, the change looks reasonable to me. Acked-by: Ard Biesheuvel > --- > arch/arm64/kernel/acpi.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index cada0b816c8a..aca5ee2a9e64 100644 > --- a/arch/arm64/kernel/acpi.c > +++ b/arch/arm64/kernel/acpi.c > @@ -246,7 +246,7 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) > * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is > * mapped to a corresponding MAIR attribute encoding. > * The EFI memory attribute advises all possible capabilities > - * of a memory region. We use the most efficient capability. > + * of a memory region. > */ > > u64 attr; > @@ -254,9 +254,7 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) > attr = efi_mem_attributes(addr); > if (attr & EFI_MEMORY_WB) > return PAGE_KERNEL; > - if (attr & EFI_MEMORY_WT) > - return __pgprot(PROT_NORMAL_WT); > - if (attr & EFI_MEMORY_WC) > + if (attr & (EFI_MEMORY_WC | EFI_MEMORY_WT)) > return __pgprot(PROT_NORMAL_NC); > return __pgprot(PROT_DEVICE_nGnRnE); > } > @@ -340,9 +338,7 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > default: > if (region->attribute & EFI_MEMORY_WB) > prot = PAGE_KERNEL; > - else if (region->attribute & EFI_MEMORY_WT) > - prot = __pgprot(PROT_NORMAL_WT); > - else if (region->attribute & EFI_MEMORY_WC) > + else if (region->attribute & (EFI_MEMORY_WC | EFI_MEMORY_WT)) > prot = __pgprot(PROT_NORMAL_NC); > } > } > -- > 2.31.1.607.g51e8a6a459-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel