From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [RFC 10/10] KVM: arm64: nv: Add new HDFGRTR2_GROUP & HDFGRTR2_GROUP based FGU handling
Date: Fri, 02 Aug 2024 11:59:03 +0100 [thread overview]
Message-ID: <86bk2b198o.wl-maz@kernel.org> (raw)
In-Reply-To: <d56735e2-3fee-4d91-84e1-a5b480ec0ce1@arm.com>
On Fri, 02 Aug 2024 10:25:44 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> On 8/1/24 21:33, Marc Zyngier wrote:
> > On Thu, 01 Aug 2024 11:46:22 +0100,
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
[...]
> >> + SR_FGT(SYS_SPMACCESSR_EL1, HDFGRTR2, nSPMACCESSR_EL1, 0),
> >
> > This (and I take it most of the stuff here) is also gated by
> > MDCR_EL2.SPM, which is a coarse grained trap. That needs to be
> > described as well. For every new register that you add here.
>
> I did not find a SPM field in MDCR_EL2 either in latest ARM ARM or in
> the latest XML. But as per current HDFGRTR2_EL2 description the field
> nSPMACCESSR_EL1 is gated by FEAT_SPMU feature, which is being checked
> via ID_AA64DFR1_EL1.PMU when required. So could you please give some
> more details.
I misspelled it. It is MDCR_EL2.EnSPM.
And you are completely missing the point. It is not about
HDFGRTR2_EL2, but about SPMACCESSR_EL1 (and all its little friends).
To convince yourself, just look at the pseudocode for SPMACCESSR_EL1,
limited to an EL1 access:
elsif PSTATE.EL == EL1 then
if HaveEL(EL3) && EL3SDDUndefPriority() && MDCR_EL3.EnPM2 == '0' then
UNDEFINED;
elsif EL2Enabled() && IsFeatureImplemented(FEAT_FGT2) && ((HaveEL(EL3) && SCR_EL3.FGTEn2 == '0') || HDFGRTR2_EL2.nSPMACCESSR_EL1 == '0') then
AArch64.SystemAccessTrap(EL2, 0x18);
elsif EL2Enabled() && MDCR_EL2.EnSPM == '0' then
AArch64.SystemAccessTrap(EL2, 0x18);
elsif HaveEL(EL3) && MDCR_EL3.EnPM2 == '0' then
if EL3SDDUndef() then
UNDEFINED;
else
AArch64.SystemAccessTrap(EL3, 0x18);
elsif EffectiveHCR_EL2_NVx() IN {'111'} then
X[t, 64] = NVMem[0x8E8];
else
X[t, 64] = SPMACCESSR_EL1;
Can you spot the *TWO* conditions where we take an exception to EL2
with 0x18 as the EC?
- One is when HDFGxTR2_EL2.nSPMACCESSR_EL1 == '0': that's a fine
grained trap.
- The other is when MDCR_EL2.EnSPM == '0': that's a coarse grained
trap.
Both conditions need to be captured in the various tables in this
file, for each and every register that you describe.
[...]
> > Now, the main issues are that:
> >
> > - you're missing the coarse grained trapping for all the stuff you
> > have just added. It's not a huge amount of work, but you need, for
> > each register, to describe what traps apply to it. The fine grained
> > stuff is most, but not all of it. There should be enough of it
> > already to guide you through it.
>
> Coarse grained trapping for FEAT_FGT2 based fine grained registers ?
Not for FEAT_FGT2. For the registers that FEAT_FGT2 traps. Can you see
the difference?
> Afraid, did not understand this. Could you please give some pointers
> on similar existing code.
See above. And if you want some example, just took at the file you are
patching already. Look at how MDCR_EL2 conditions the trapping of all
the debug, PMU, AMU registers, for example. There is no shortage of
them.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-08-02 10:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 6:57 [RFC 00/10] KVM: arm64: Enable fine grained undefined for MDSELR_EL1 Anshuman Khandual
2024-06-20 6:57 ` [RFC 01/10] arm64/sysreg: Update ID_AA64MMFR0_EL1 register Anshuman Khandual
2024-06-20 6:57 ` [RFC 02/10] arm64/sysreg: Update ID_AA64DFR0_EL1 register Anshuman Khandual
2024-06-20 6:58 ` [RFC 03/10] arm64/sysreg: Add register fields for ID_AA64DFR2_EL1 Anshuman Khandual
2024-06-20 6:58 ` [RFC 04/10] arm64/sysreg: Add register fields for HDFGRTR2_EL2 Anshuman Khandual
2024-06-20 6:58 ` [RFC 05/10] arm64/sysreg: Add register fields for HDFGWTR2_EL2 Anshuman Khandual
2024-06-20 6:58 ` [RFC 06/10] arm64/sysreg: Add register fields for MDSELR_EL1 Anshuman Khandual
2024-06-20 6:58 ` [RFC 07/10] arm64/sysreg: Add register fields for PMSID_EL1 Anshuman Khandual
2024-06-20 6:58 ` [RFC 08/10] arm64/sysreg: Add register fields for TRBIDR_EL1 Anshuman Khandual
2024-06-20 6:58 ` [RFC 09/10] KVM: arm64: nv: Enable HDFGRTR2_EL2 & HDFGWTR2_EL2 access from virtual EL2 Anshuman Khandual
2024-06-20 6:58 ` [RFC 10/10] KVM: arm64: nv: Add new HDFGRTR2_GROUP & HDFGRTR2_GROUP based FGU handling Anshuman Khandual
2024-06-20 11:06 ` Marc Zyngier
2024-06-21 7:56 ` Anshuman Khandual
2024-06-21 11:24 ` Marc Zyngier
2024-06-25 9:03 ` Anshuman Khandual
2024-06-25 13:58 ` Marc Zyngier
2024-08-01 10:46 ` Anshuman Khandual
2024-08-01 16:03 ` Marc Zyngier
2024-08-02 9:25 ` Anshuman Khandual
2024-08-02 10:59 ` Marc Zyngier [this message]
2024-08-03 10:38 ` Anshuman Khandual
2024-08-04 11:05 ` Marc Zyngier
2024-08-13 6:53 ` Anshuman Khandual
2024-08-13 7:16 ` Marc Zyngier
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=86bk2b198o.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@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 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).