All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Christoph Hellwig <hch@lst.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Subject: Re: [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC
Date: Thu, 6 May 2021 13:30:18 +0200	[thread overview]
Message-ID: <CAMj1kXHefR0Pmbz7hR1TVNNoQCwBEV+=eRS1NXo0o4i1BhmnJQ@mail.gmail.com> (raw)
In-Reply-To: <20210506110008.GC32366@C02TD0UTHF1T.local>

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

  reply	other threads:[~2021-05-06 11:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06  9:50 [PATCH 0/3] Free up a couple of MAIRs Will Deacon
2021-05-06  9:50 ` [PATCH 1/3] arm64: mm: Remove unused support for Device-GRE memory type Will Deacon
2021-05-06 13:25   ` Catalin Marinas
2021-05-06  9:50 ` [PATCH 2/3] arm64: acpi: Map EFI_MEMORY_WT memory as Normal-NC Will Deacon
2021-05-06 10:14   ` Ard Biesheuvel
2021-05-06 13:25     ` Catalin Marinas
2021-05-06 17:45       ` Ard Biesheuvel
2021-05-06 10:20   ` Mark Rutland
2021-05-06 10:46     ` Will Deacon
2021-05-06 11:00       ` Mark Rutland
2021-05-06 11:30         ` Ard Biesheuvel [this message]
2021-05-06  9:50 ` [PATCH 3/3] arm64: mm: Remove unused support for Normal-WT memory type Will Deacon
2021-05-06 13:26   ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMj1kXHefR0Pmbz7hR1TVNNoQCwBEV+=eRS1NXo0o4i1BhmnJQ@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.