Free up a couple of MAIRs

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

Cc Christoph Hellwig <[email protected]>

Suggested-by Catalin Marinas <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

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 <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Christoph Hellwig <[email protected]>

Signed-off-by Will Deacon <[email protected]>

---
 arch/arm64/kernel/acpi.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

arch/arm64/kernel/acpi.c +3 -8

index cada0b816c8a..aca5ee2a9e64 100644
@@ -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

Quoted 11 lines · 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 <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Christoph Hellwig <[email protected]>

Signed-off-by Will Deacon <[email protected]>

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.

Quoted 20 lines · Ard Biesheuvel

Quoted 11 lines · 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 <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Christoph Hellwig <[email protected]>

Signed-off-by Will Deacon <[email protected]>

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.

Quoted 4 lines

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 <[email protected]>

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 <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Christoph Hellwig <[email protected]>

Signed-off-by Will Deacon <[email protected]>

---
 arch/arm64/kernel/acpi.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

arch/arm64/kernel/acpi.c +3 -7

index cada0b816c8a..aca5ee2a9e64 100644
@@ -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);
 		}
 	}

Signature · 7 lines

2.31.1.607.g51e8a6a459-goog


_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 5 lines · 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.

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.

Quoted 9 lines · Mark Rutland

Quoted 5 lines · 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.

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

Quoted 11 lines

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?

Quoted 31 lines · Will Deacon

Quoted 9 lines · Mark Rutland

Quoted 5 lines · 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.

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

Quoted 11 lines

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.

Quoted 2 lines

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.

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

Cc Christoph Hellwig <[email protected]>

Signed-off-by Will Deacon <[email protected]>