All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Independently update HDFGRTR_EL2 and HDFGWTR_EL2
Date: Thu, 19 Oct 2023 08:15:03 +0100	[thread overview]
Message-ID: <8734y76q2w.wl-maz@kernel.org> (raw)
In-Reply-To: <d8db313d-1161-4a6e-9edc-7dc1e22d2018@arm.com>

On Thu, 19 Oct 2023 04:36:15 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> 
> 
> 
> On 10/18/23 18:10, 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.
> > 
> > Also, what is nBRBIDR doing here? It is still set to 0. What
> > 'RESERVED' state are you talking about?
> 
> Let's observe the following example which includes the nBRBIDR problem,
> mentioned earlier.
> 
> Read access trap configure
> 
> HDFGRTR_EL2[59]	   - nBRBIDR
> HDFGRTR_EL2[58]	   - PMCEIDn_EL0
> 
> Write access trap configure
> 
> HDFGWTR_EL2[59:58] - RES0
> 
> Because BRBIDR_EL1 and PMCEID<N>_EL0 are read only registers they don't
> have corresponding entries in HDFGWTR_EL2 for write trap configuration.
> 
> Using the exact same value contained in 'x0' both for HDFGRTR_EL2, and
> HDFGWTR_EL2 will be problematic in case it contains bit fields that are
> available only in one of the registers but not in the other.
> 
> If 'x0' contains nBRBIDR being set, it will be okay for HDFGRTR_EL2 but
> might not be okay for HDFGWTR_EL2 where it will get into RESERVED areas.

None of which matters for this patch. You keep arguing about something
that does not exist in the change you're proposing.

[...]

> I should have given more details in the commit message but hope
> you have some context now, but please do let me know if there
> is something still missing.

What is missing is a useful patch. This one just obfuscates things for
no particular purpose. If you have a useful change to contribute,
please send that instead (your BRBE change). We don't need an extra,
standalone and pointless patch such as this one.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Independently update HDFGRTR_EL2 and HDFGWTR_EL2
Date: Thu, 19 Oct 2023 08:15:03 +0100	[thread overview]
Message-ID: <8734y76q2w.wl-maz@kernel.org> (raw)
In-Reply-To: <d8db313d-1161-4a6e-9edc-7dc1e22d2018@arm.com>

On Thu, 19 Oct 2023 04:36:15 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> 
> 
> 
> On 10/18/23 18:10, 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.
> > 
> > Also, what is nBRBIDR doing here? It is still set to 0. What
> > 'RESERVED' state are you talking about?
> 
> Let's observe the following example which includes the nBRBIDR problem,
> mentioned earlier.
> 
> Read access trap configure
> 
> HDFGRTR_EL2[59]	   - nBRBIDR
> HDFGRTR_EL2[58]	   - PMCEIDn_EL0
> 
> Write access trap configure
> 
> HDFGWTR_EL2[59:58] - RES0
> 
> Because BRBIDR_EL1 and PMCEID<N>_EL0 are read only registers they don't
> have corresponding entries in HDFGWTR_EL2 for write trap configuration.
> 
> Using the exact same value contained in 'x0' both for HDFGRTR_EL2, and
> HDFGWTR_EL2 will be problematic in case it contains bit fields that are
> available only in one of the registers but not in the other.
> 
> If 'x0' contains nBRBIDR being set, it will be okay for HDFGRTR_EL2 but
> might not be okay for HDFGWTR_EL2 where it will get into RESERVED areas.

None of which matters for this patch. You keep arguing about something
that does not exist in the change you're proposing.

[...]

> I should have given more details in the commit message but hope
> you have some context now, but please do let me know if there
> is something still missing.

What is missing is a useful patch. This one just obfuscates things for
no particular purpose. If you have a useful change to contribute,
please send that instead (your BRBE change). We don't need an extra,
standalone and pointless patch such as this one.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-10-19  7:15 UTC|newest]

Thread overview: 12+ 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  3:00 ` Anshuman Khandual
2023-10-18 12:40 ` Marc Zyngier
2023-10-18 12:40   ` Marc Zyngier
2023-10-18 20:16   ` Oliver Upton
2023-10-18 20:16     ` Oliver Upton
2023-10-19  3:36   ` Anshuman Khandual
2023-10-19  3:36     ` Anshuman Khandual
2023-10-19  7:15     ` Marc Zyngier [this message]
2023-10-19  7:15       ` Marc Zyngier
2023-10-19  8:31       ` Anshuman Khandual
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=8734y76q2w.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    --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.