On Wed, Mar 23, 2022 at 07:53:14PM +0000, Oliver Upton 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. Aren't AArch64 ID regs architecturally mapped to their AArch32 counterparts? They should show the same values. I'm not sure if it's a problem (and if KVM is faithful to that rule), > > 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? > > -- > Thanks, > Oliver
