[PATCH 3/4] KVM: arm64: show writable masks for feature registers

[Marc Zyngier]

On Mon, 18 Mar 2024 18:20:06 +0000,
Sebastian Ott <sebott at redhat.com> wrote:
> 
> On Mon, 18 Mar 2024, Marc Zyngier wrote:
> > On Mon, 18 Mar 2024 11:16:35 +0000,
> > Sebastian Ott <sebott at redhat.com> wrote:
> >> 
> >> Instead of using ~0UL provide the actual writable mask for
> >> non-id feature registers in the output of the
> >> KVM_ARM_GET_REG_WRITABLE_MASKS ioctl.
> > 
> > CTR_EL0 definitely seems to be in the feature ID range. And so does
> > CLIDR_EL1.
> 
> Sry, bad wording. I mean feature id regs for which is_id_reg() is false.
>

Maybe this means that we should revisit the range delineated by
is_id_reg().

> >> 
> >> This changes the mask for the CTR_EL0 register.
> > 
> > Only that?
> 
> Yes.

The patch shows otherwise, I'm afraid.

> 
> >> Signed-off-by: Sebastian Ott <sebott at redhat.com>
> >> ---
> >>  arch/arm64/kvm/sys_regs.c | 21 ++++++---------------
> >>  1 file changed, 6 insertions(+), 15 deletions(-)
> >> 
> >> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >> index b2019faa9d73..0f8fe7790c35 100644
> >> --- a/arch/arm64/kvm/sys_regs.c
> >> +++ b/arch/arm64/kvm/sys_regs.c
> >> @@ -2489,12 +2489,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> >> 
> >>  	{ SYS_DESC(SYS_CCSIDR_EL1), access_ccsidr },
> >>  	{ SYS_DESC(SYS_CLIDR_EL1), access_clidr, reset_clidr, CLIDR_EL1,
> >> -	  .set_user = set_clidr },
> >> +	  .set_user = set_clidr, .val = ~0UL },
> > 
> > How is CLIDR_EL1 (and all the crap that depend on it) recomputed when
> > CTR_EL0 is changed?
> 
> Do we have means to handle dependencies here? There is no natural order
> in which userspace is writing to these regs. Nor a good time or a trigger
> when the kernel should do a sanity/dependency check..

Well, we're not going to run the guest with something that describes
an inconsistent topology either, so this is the very first thing that
needs to be solved.

Either by restoring acceptable defaults when the topology changes due
to a write to CTR_EL0, or by returning an error to userspace if the
cache topology has been restored but CTR_EL0 is incompatible with it.

	M.

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