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@xxxxxxxxxx> 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@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) > > > > 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.
