linux-arm-kernel.lists.infradead.org archive mirror
 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,
	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.


  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).