[PATCH 0/3] Free up a couple of MAIRs

[PATCH 0/3] Free up a couple of MAIRs

[Will Deacon]

Hi folks,

Catalin pointed out that the Device-GRE memory type is unused, despite
having a MAIR allocation. In removing that, I noticed that we also
allocate Normal-WT despite it only being used for EFI_MEMORY_WT mappings,
which can use Normal-NC instead.

With these changes, we free up a couple of MAIR entries for more
interesting things (e.g. outer cacheability attributes if we need them
in future for the SLC).

Patches taken against the arm64 for-next/core branch.

Cheers,

Will

Cc: Christoph Hellwig <hch@lst.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

--->8

Will Deacon (3):
  arm64: mm: Remove unused support for Device-GRE memory type
  arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC
  arm64: mm: Remove unused support for Normal-WT memory type

 arch/arm64/include/asm/memory.h       |  6 ++----
 arch/arm64/include/asm/pgtable-prot.h |  1 -
 arch/arm64/include/asm/sysreg.h       |  2 --
 arch/arm64/kernel/acpi.c              | 10 +++-------
 arch/arm64/mm/proc.S                  |  2 --
 arch/arm64/mm/ptdump.c                |  4 ----
 6 files changed, 5 insertions(+), 20 deletions(-)

-- 
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

[PATCH 1/3] arm64: mm: Remove unused support for Device-GRE memory type

[Will Deacon]

The Device-GRE memory type is unused, so remove it and reclaim a MAIR.

Cc: Christoph Hellwig <hch@lst.de>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210505180228.GA3874@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/include/asm/memory.h | 1 -
 arch/arm64/include/asm/sysreg.h | 1 -
 arch/arm64/mm/proc.S            | 1 -
 arch/arm64/mm/ptdump.c          | 4 ----
 4 files changed, 7 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 15018dc59554..ea268be37ea2 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -138,7 +138,6 @@
 #define MT_NORMAL_WT		3
 #define MT_DEVICE_nGnRnE	4
 #define MT_DEVICE_nGnRE		5
-#define MT_DEVICE_GRE		6
 
 /*
  * Memory types for Stage-2 translation
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index b31ac5ccc8ab..aa8e53dd8686 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -651,7 +651,6 @@
 /* MAIR_ELx memory attributes (used by Linux) */
 #define MAIR_ATTR_DEVICE_nGnRnE		UL(0x00)
 #define MAIR_ATTR_DEVICE_nGnRE		UL(0x04)
-#define MAIR_ATTR_DEVICE_GRE		UL(0x0c)
 #define MAIR_ATTR_NORMAL_NC		UL(0x44)
 #define MAIR_ATTR_NORMAL_WT		UL(0xbb)
 #define MAIR_ATTR_NORMAL_TAGGED		UL(0xf0)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 0a48191534ff..be6e5d1e3673 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -58,7 +58,6 @@
 #define MAIR_EL1_SET							\
 	(MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) |	\
 	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) |	\
-	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) |		\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) |		\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) |			\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) |		\
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index a1937dfff31c..1c403536c9bb 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -157,10 +157,6 @@ static const struct prot_bits pte_bits[] = {
 		.mask	= PTE_ATTRINDX_MASK,
 		.val	= PTE_ATTRINDX(MT_DEVICE_nGnRE),
 		.set	= "DEVICE/nGnRE",
-	}, {
-		.mask	= PTE_ATTRINDX_MASK,
-		.val	= PTE_ATTRINDX(MT_DEVICE_GRE),
-		.set	= "DEVICE/GRE",
 	}, {
 		.mask	= PTE_ATTRINDX_MASK,
 		.val	= PTE_ATTRINDX(MT_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

Re: [PATCH 1/3] arm64: mm: Remove unused support for Device-GRE memory type

[Catalin Marinas]

On Thu, May 06, 2021 at 10:50:32AM +0100, Will Deacon wrote:
> The Device-GRE memory type is unused, so remove it and reclaim a MAIR.
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Link: https://lore.kernel.org/r/20210505180228.GA3874@arm.com
> Signed-off-by: Will Deacon <will@kernel.org>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

(unless you want me to queue them as clean-ups for 5.13)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Will Deacon]

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 <ardb@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Will Deacon <will@kernel.org>
---
 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

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Ard Biesheuvel]

On Thu, 6 May 2021 at 11:50, Will Deacon <will@kernel.org> 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 <ardb@kernel.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Will Deacon <will@kernel.org>

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 <ardb@kernel.org>




> ---
>  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

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Catalin Marinas]

On Thu, May 06, 2021 at 12:14:55PM +0200, Ard Biesheuvel wrote:
> On Thu, 6 May 2021 at 11:50, Will Deacon <will@kernel.org> 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 <ardb@kernel.org>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Will Deacon <will@kernel.org>
> 
> 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.

In theory there's a slight difference between WT and WC/Normal-NC as
reads are allowed to hit into the cache while for WC/Normal-NC they
aren't (somehow implied on page B2-168 in the ARMv8 ARM G.a). Whether
they must hit in the cache is not entirely clear, I don't think they
have to. The mismatched aliases section doesn't guarantee coherency
between accesses using different WC and WB attributes (point 1,
attributes must be the same for both reads and writes). Appendix K4.1.1
also suggest that WT could be implemented as Normal-NC.

So I don't think EFI can rely on any specific WT behaviour other than
maybe slightly better performance.

So:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Ard Biesheuvel]

On Thu, 6 May 2021 at 15:25, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, May 06, 2021 at 12:14:55PM +0200, Ard Biesheuvel wrote:
> > On Thu, 6 May 2021 at 11:50, Will Deacon <will@kernel.org> 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 <ardb@kernel.org>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Christoph Hellwig <hch@lst.de>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > 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.
>
> In theory there's a slight difference between WT and WC/Normal-NC as
> reads are allowed to hit into the cache while for WC/Normal-NC they
> aren't (somehow implied on page B2-168 in the ARMv8 ARM G.a). Whether
> they must hit in the cache is not entirely clear, I don't think they
> have to. The mismatched aliases section doesn't guarantee coherency
> between accesses using different WC and WB attributes (point 1,
> attributes must be the same for both reads and writes). Appendix K4.1.1
> also suggest that WT could be implemented as Normal-NC.
>
> So I don't think EFI can rely on any specific WT behaviour other than
> maybe slightly better performance.
>

For the record, this mostly affects mappings created by the ACPI core,
for things like RAS handling in firmware. EFI itself is not really a
part of this, but given that ACPI lacks any way to annotate memory
types for OpRegions (as x86 does not need this), we cross reference
ACPI memory map requests with the EFI memory map to infer the right
type.

For RAS in particular, I can see how firmware might rely on
non-cacheable behavior for correctness (e.g., for publishing error
records in a way that ensures they are visible to other agents, such
as a BMC), but I still don't think treating WT as WC will make a
material difference here.


> So:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Mark Rutland]

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<n> value).

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.

Thanks,
Mark.

> 
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Will Deacon]

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<n> 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

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Mark Rutland]

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<n> 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

Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC

[Ard Biesheuvel]

On Thu, 6 May 2021 at 13:00, Mark Rutland <mark.rutland@arm.com> wrote:
>
> 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<n> 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.
>

EFI memory types are not exclusive. Most implementations use WB|WT|WC
for all memory, and some even use WB|WT|WC|UC, which means that the OS
can use whichever attributes it wants.

So we should only warn in cases where WT is specified but WC is not,
and I've never seen firmware that does this.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] arm64: mm: Remove unused support for Normal-WT memory type

[Will Deacon]

The Normal-WT memory type is unused, so remove it and reclaim a MAIR.

Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/include/asm/memory.h       | 5 ++---
 arch/arm64/include/asm/pgtable-prot.h | 1 -
 arch/arm64/include/asm/sysreg.h       | 1 -
 arch/arm64/mm/proc.S                  | 1 -
 4 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index ea268be37ea2..865fa2ab51b2 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -135,9 +135,8 @@
 #define MT_NORMAL		0
 #define MT_NORMAL_TAGGED	1
 #define MT_NORMAL_NC		2
-#define MT_NORMAL_WT		3
-#define MT_DEVICE_nGnRnE	4
-#define MT_DEVICE_nGnRE		5
+#define MT_DEVICE_nGnRnE	3
+#define MT_DEVICE_nGnRE		4
 
 /*
  * Memory types for Stage-2 translation
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index fab2f573f7a4..8923c9b119ae 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -55,7 +55,6 @@ extern bool arm64_use_ng_mappings;
 #define PROT_DEVICE_nGnRnE	(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_DEVICE_nGnRnE))
 #define PROT_DEVICE_nGnRE	(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_DEVICE_nGnRE))
 #define PROT_NORMAL_NC		(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC))
-#define PROT_NORMAL_WT		(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT))
 #define PROT_NORMAL		(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
 #define PROT_NORMAL_TAGGED	(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_TAGGED))
 
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index aa8e53dd8686..ec27455d2a44 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -652,7 +652,6 @@
 #define MAIR_ATTR_DEVICE_nGnRnE		UL(0x00)
 #define MAIR_ATTR_DEVICE_nGnRE		UL(0x04)
 #define MAIR_ATTR_NORMAL_NC		UL(0x44)
-#define MAIR_ATTR_NORMAL_WT		UL(0xbb)
 #define MAIR_ATTR_NORMAL_TAGGED		UL(0xf0)
 #define MAIR_ATTR_NORMAL		UL(0xff)
 #define MAIR_ATTR_MASK			UL(0xff)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index be6e5d1e3673..c2d57eb0e671 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -60,7 +60,6 @@
 	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) |	\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) |		\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) |			\
-	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) |		\
 	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
 
 #ifdef CONFIG_CPU_PM
-- 
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

Re: [PATCH 3/3] arm64: mm: Remove unused support for Normal-WT memory type

[Catalin Marinas]

On Thu, May 06, 2021 at 10:50:34AM +0100, Will Deacon wrote:
> The Normal-WT memory type is unused, so remove it and reclaim a MAIR.
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Will Deacon <will@kernel.org>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel