[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMn1gO5Va0eVFqzoOLLLJ+C+x-5=cc4qXDTw0e9J7v0RpYWusA@mail.gmail.com>
Date: Tue, 9 Aug 2022 18:24:23 -0700
From: Peter Collingbourne <pcc@...gle.com>
To: Evgenii Stepanov <eugenis@...gle.com>
Cc: Marc Zyngier <maz@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Andrey Konovalov <andreyknvl@...il.com>,
Mark Brown <broonie@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mte: Follow arm64.nomte override in MMU setup.
On Tue, Aug 9, 2022 at 10:29 AM Evgenii Stepanov <eugenis@...gle.com> wrote:
>
> On Tue, Aug 9, 2022 at 9:49 AM Marc Zyngier <maz@...nel.org> wrote:
> >
> > In which case what is the tag memory doing in the linear map?
> > Shouldn't it be marked as reserved, not mapped, and in general
> > completely ignored by the NS OS?
>
> That would be wasteful. The idea is to only reserve the parts of the
> tag memory that correspond to the TZ carveout and release the rest to
> the NS OS.
More generally, one can imagine a system where *any* tagged memory
transaction can result in an SError because the MTE implementation was
not configured by an earlier bootloader phase, e.g. because the
bootloader was configured to disable MTE at runtime. On such systems,
the kernel must refrain from causing tagged memory transactions to be
issued via the linear map, and that's exactly what this patch does.
Peter
Powered by blists - more mailing lists