[PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table

[Oliver Upton]

On Thu, Mar 24, 2022 at 10:15:41PM -0700, Reiji Watanabe wrote:
> On Thu, Mar 24, 2022 at 4:01 PM Oliver Upton <oupton at google.com> wrote:
> >
> > On Thu, Mar 24, 2022 at 01:23:42PM -0700, Reiji Watanabe wrote:
> > > Hi Oliver,
> > >
> > > On Wed, Mar 23, 2022 at 12:53 PM Oliver Upton <oupton at google.com> wrote:
> > > >
> > > > Hi Reiji,
> > > >
> > > > On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote:
> > > > > Add hidden or reserved ID registers, and remaining ID registers,
> > > > > which don't require special handling, to id_reg_desc_table.
> > > > > Add 'flags' field to id_reg_desc, which is used to indicates hiddden
> > > > > or reserved registers. Since now id_reg_desc_init() is called even
> > > > > for hidden/reserved registers, change it to not do anything for them.
> > > > >
> > > > > Signed-off-by: Reiji Watanabe <reijiw at google.com>
> > > >
> > > > I think there is a very important detail of the series that probably
> > > > should be highlighted. We are only allowing AArch64 feature registers to
> > > > be configurable, right? AArch32 feature registers remain visible with
> > > > their default values passed through to the guest. If you've already
> > > > stated this as a precondition elsewhere then my apologies for the noise.
> > > >
> > > > I don't know if adding support for this to AArch32 registers is
> > > > necessarily the right step forward, either. 32 bit support is working
> > > > just fine and IMO its OK to limit new KVM features to AArch64-only so
> > > > long as it doesn't break 32 bit support. Marc of course is the authority
> > > > on that, though :-)
> > > >
> > > > If for any reason a guest uses a feature present in the AArch32 feature
> > > > register but hidden from the AArch64 register, we could be in a
> > > > particularly difficult position. Especially if we enabled traps based on
> > > > the AArch64 value and UNDEF the guest.
> > > >
> > > > One hack we could do is skip trap configuration if AArch32 is visible at
> > > > either EL1 or EL0, but that may not be the most elegant solution.
> > > > Otherwise, if we are AArch64-only at every EL then the definition of the
> > > > AArch32 feature registers is architecturally UNKNOWN, so we can dodge
> > > > the problem altogether. What are your thoughts?
> > >
> > > Thank you so much for your review, Oliver!
> > >
> > > For aarch32 guests (when KVM_ARM_VCPU_EL1_32BIT is configured),
> > > yes, the current series is problematic as you mentioned...
> > > I am thinking of disallowing configuring ID registers (keep ID
> > > registers immutable) for the aarch32 guests for now at least.
> > > (will document that)
> >
> > That fixes it halfway, but the AArch64 views of the AArch32 feature
> > registers have meaning even if AArch32 is defined at EL0. The only time
> > they are architecturally UNKNOWN is if AArch32 is not implemented at any
> > EL visible to the guest.
> >
> > So, given that:
> >
> > > For aarch64 guests that support EL0 aarch32, it would generally
> > > be a userspace bug if userspace sets inconsistent values in 32bit
> > > and 64bit ID registers. KVM doesn't provide a complete consistency
> > > checking for ID registers, but this could be added later as needed.
> >
> > I completely agree that there is a large set of things that can be swept
> > under the rug of userspace bugs. If we are going to do that, we need to
> > strongly assert that configurable feature registers is only for fully
> > AArch64-only guests. Additionally, strong documentation around these
> > expectations is required.
> 
> Just to be clear, what I meant "this could be added later" is that
> the feature consistency checking between 64bit ID registers and 32bit ID
> registers could be added later.  It means configuring ID registers
> itself will be allowed for EL1 aarch64 guests including ones that
> support EL0 aarch32 (but not for EL1 aarch32 guests).
> 

I believe we are in agreement then. I don't believe there is any need
to prohibit register accesses for the case of AArch32 EL1, given the
fact that it is impossible to read the ID_AA64*_EL1 registers from the
guest anyway.

We can go ahead and let userspace play with those registers as much as
it wants, it delightfully has no affect :)

> > Mind you, these opinions are my own and IDK how others or Marc feel
> > about it. My read of the situation w.r.t. the AArch32 registers is that
> > it will become a mess to implement on top of the AArch64 registers.
> > Given the fact that we aren't breaking AArch32 VMs, only augmenting
> > behavior for AArch64, it seems OK.
> 
> Thank you for sharing your thoughts.
> They look almost the same as what I've been thinking.
> 
> Thanks,
> Reiji
> 
> 
> > But I would genuinely love to be wrong on this topic too. I just don't
> > have perspective on AArch32 users so it is hard to really say whether
> > this is something they need as well.