From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Independently update HDFGRTR_EL2 and HDFGWTR_EL2
Date: Wed, 18 Oct 2023 20:16:06 +0000 [thread overview]
Message-ID: <ZTA9BlmagUv1teh7@linux.dev> (raw)
In-Reply-To: <86r0lsm7cq.wl-maz@kernel.org>
On Wed, Oct 18, 2023 at 01:40:37PM +0100, Marc Zyngier wrote:
> On Wed, 18 Oct 2023 04:00:07 +0100,
> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >
> > Currently PMSNEVFR_EL1 system register read, and write access EL2 traps are
> > disabled, via setting the same bit (i.e 62) in HDFGRTR_EL2, and HDFGWTR_EL2
> > respectively. Although very similar, bit fields are not exact same in these
> > two EL2 trap configure registers particularly when it comes to read-only or
> > write-only accesses such as ready-only 'HDFGRTR_EL2.nBRBIDR' which needs to
> > be set while enabling BRBE on NVHE platforms. Using the exact same bit mask
> > fields for both these trap register risk writing into their RESERVED areas,
> > which is undesirable.
>
> Sorry, I don't understand at all what you are describing. You seem to
> imply that the read and write effects of the FGT doesn't apply the
> same way. But my reading of the ARM ARM is that behave completely
> symmetrically.
nBRBIDR is an asymmetric bit (bit 59 of HDFGWTR_EL2 is RES0). While the
architecture *could* repurpose this WTR bit for something else, that
feels rather implementation and software hostile. I don't think there's
a practical issue here, especially since the architecture has already
allocated another pair of debug trap registers to make room for more
bits.
> So what has changed here, aside from clobbering an extra register? The
> masks are the same, the initial values are the same... Is it in
> preparation for some other work?
Yeah, it feels as though this patch is taken out of context. Without a
justifying functional change I don't see the value in fiddling with this
code.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-18 20:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 3:00 [PATCH] arm64: Independently update HDFGRTR_EL2 and HDFGWTR_EL2 Anshuman Khandual
2023-10-18 12:40 ` Marc Zyngier
2023-10-18 20:16 ` Oliver Upton [this message]
2023-10-19 3:36 ` Anshuman Khandual
2023-10-19 7:15 ` Marc Zyngier
2023-10-19 8:31 ` Anshuman Khandual
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=ZTA9BlmagUv1teh7@linux.dev \
--to=oliver.upton@linux.dev \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).