From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Mark Brown <broonie@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mte: Follow arm64.nomte override in MMU setup.
Date: Tue, 16 Aug 2022 08:51:47 +0100 [thread overview]
Message-ID: <YvtMk2cNDrrzVX3g@arm.com> (raw)
In-Reply-To: <CAMn1gO5Va0eVFqzoOLLLJ+C+x-5=cc4qXDTw0e9J7v0RpYWusA@mail.gmail.com>
On Tue, Aug 09, 2022 at 06:24:23PM -0700, Peter Collingbourne wrote:
> On Tue, Aug 9, 2022 at 10:29 AM Evgenii Stepanov <eugenis@google.com> wrote:
> > On Tue, Aug 9, 2022 at 9:49 AM Marc Zyngier <maz@kernel.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.
The problem is that it doesn't. The 8.5 architecture allows any Normal
Cacheable (even non-tagged) mapping to fetch tags. It may happen that on
certain implementations setting MAIR to non-tagged works but that's not
guaranteed and with the Linux kernel we tend to stick to the architected
behaviour (with a few exceptions like PMU counters and errata).
There is an ongoing discussion with the architects and partners on
whether we can tighten the architecture as not to cause visible
side-effects like SError but not sure whether that has been closed yet
(just back from holiday).
Until that's sorted, tag storage cannot be reused in an arm64-generic
way in the kernel.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Mark Brown <broonie@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mte: Follow arm64.nomte override in MMU setup.
Date: Tue, 16 Aug 2022 08:51:47 +0100 [thread overview]
Message-ID: <YvtMk2cNDrrzVX3g@arm.com> (raw)
In-Reply-To: <CAMn1gO5Va0eVFqzoOLLLJ+C+x-5=cc4qXDTw0e9J7v0RpYWusA@mail.gmail.com>
On Tue, Aug 09, 2022 at 06:24:23PM -0700, Peter Collingbourne wrote:
> On Tue, Aug 9, 2022 at 10:29 AM Evgenii Stepanov <eugenis@google.com> wrote:
> > On Tue, Aug 9, 2022 at 9:49 AM Marc Zyngier <maz@kernel.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.
The problem is that it doesn't. The 8.5 architecture allows any Normal
Cacheable (even non-tagged) mapping to fetch tags. It may happen that on
certain implementations setting MAIR to non-tagged works but that's not
guaranteed and with the Linux kernel we tend to stick to the architected
behaviour (with a few exceptions like PMU counters and errata).
There is an ongoing discussion with the architects and partners on
whether we can tighten the architecture as not to cause visible
side-effects like SError but not sure whether that has been closed yet
(just back from holiday).
Until that's sorted, tag storage cannot be reused in an arm64-generic
way in the kernel.
--
Catalin
next prev parent reply other threads:[~2022-08-16 7:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 21:47 [PATCH] mte: Follow arm64.nomte override in MMU setup Evgenii Stepanov
2022-08-05 21:47 ` Evgenii Stepanov
2022-08-09 8:50 ` Marc Zyngier
2022-08-09 8:50 ` Marc Zyngier
2022-08-09 16:41 ` Evgenii Stepanov
2022-08-09 16:41 ` Evgenii Stepanov
2022-08-09 16:49 ` Marc Zyngier
2022-08-09 16:49 ` Marc Zyngier
2022-08-09 17:29 ` Evgenii Stepanov
2022-08-09 17:29 ` Evgenii Stepanov
2022-08-10 1:24 ` Peter Collingbourne
2022-08-10 1:24 ` Peter Collingbourne
2022-08-16 7:51 ` Catalin Marinas [this message]
2022-08-16 7:51 ` Catalin Marinas
2022-08-17 5:38 ` Peter Collingbourne
2022-08-17 5:38 ` Peter Collingbourne
2022-08-18 16:33 ` Catalin Marinas
2022-08-18 16:33 ` 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=YvtMk2cNDrrzVX3g@arm.com \
--to=catalin.marinas@arm.com \
--cc=andreyknvl@gmail.com \
--cc=broonie@kernel.org \
--cc=eugenis@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=pcc@google.com \
--cc=vincenzo.frascino@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.