On Thu, 22 Aug 2024 16:30:42 +0100,
Mark Brown [off-list ref] wrote:

[1  <text/plain; us-ascii (quoted-printable)>]
On Wed, Aug 21, 2024 at 05:40:06PM +0100, Marc Zyngier wrote:

quoted

Mark Brown [off-list ref] wrote:

quoted

quoted

Indeed, I was wondering about just adding a description of the relevant
ID register field to the sys_regs table.

quoted

You'd need more than that.

quoted

How would you express the visibility of TCR2_EL2? It depends on both
ID_AA64PFR0_EL1.EL2==1 *and* ID_AA64MMFR3_EL1.TCRX==1. So it cannot be
just a single tuple { idreg, field, value }. It needs to be an
arbitrary conjunction of those.

I haven't done an audit for fun cases to see how viable things are, for
the EL2 cases I'd just have an encoding based check for EL2 rather than
explicitly enumerating the ID register for each EL2.  That seemed
quicker and less error prone.

Sure, you can do that. Or rather, you can do that *right now*. But
that's not what the architecture says (there is no statement saying
that Op1==4 for an EL2 register). So the forward-looking way to do it
is to match the full encoding of a register against the properties
that define its existence.  Anything else is a short lived hack, and I
don't care much for them.

But a simple way to deal with that is to encode a property that checks
a vcpu creation property (EL2, PAuth...).

The other cases I'm aware of are more along the lines of features
restricting the values other features/idregs can have (eg, for SME the
information in ID_AA64PFR1_EL1.SME can also be gleaned from
ID_AA64SMFR0_EL1.SMEver).

Well, they don't quite advertise the same thing. If you decode the
feature specification, you get:

(FEAT_SME <-> (AArch64 ID_AA64PFR1_EL1.SME >= 1))
(FEAT_SME2 --> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 1))
(FEAT_SME2 --> (AArch64 ID_AA64PFR1_EL1.SME >= 2))
(((AArch64 ID_AA64SMFR0_EL1.SMEver >= 1) || (AArch64 ID_AA64PFR1_EL1.SME >= 2)) --> FEAT_SME2)
(FEAT_SME2p1 <-> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 2))

So SME isn't really advertised in SMEver, SME2 is advertised in both
(and it is enough that one advertises SME2 for the feature to be
present), and SME2p1 is only advertised in SMEver.

That's what we need to implement. Yes, this part of the architecture
is... interesting.

For those I'm not sure if visibility checks
are the best approach, if we should audit the registers when starting
the guest to make sure they're self consistent or if we should just pick
the most directly relevant register and rely on userspace to enforce
consistancy.

We definitely rely on userspace to enforce consistency. If userspace
messes up, it's "garbage in, garbage out".

We enforce the sysregs visible by the guest and userspace based on
that, and if that means evaluating 10 registers because there is a
terrible set of combinations (such as PAuth-like features), so be it.
We can always find ways to accelerate that.

	M.

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