Hi Oliver, On Wed, Mar 23, 2022 at 12:53 PM Oliver Upton <oupton@xxxxxxxxxx> 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@xxxxxxxxxx> > > 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) 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. It might be a good idea to skip trap configuration to avoid being affected by the issue. On the other hand, this might provide a good opportunity to detect such userspace issue. As this could happen only with new userspace code that changes ID registers, I might rather prefer the latter? Thanks, Reiji
