Hi Oliver, On Sun, Apr 3, 2022 at 10:46 PM Oliver Upton <oupton@xxxxxxxxxx> wrote: > > Hi Reiji, > > On Sun, Apr 03, 2022 at 09:45:15PM -0700, Reiji Watanabe wrote: > > On Thu, Mar 31, 2022 at 6:08 PM Oliver Upton <oupton@xxxxxxxxxx> wrote: > > > > > > To date KVM has not trapped ID register accesses from AArch32, meaning > > > that guests get an unconstrained view of what hardware supports. This > > > can be a serious problem because we try to base the guest's feature > > > registers on values that are safe system-wide. Furthermore, KVM does not > > > implement the latest ISA in the PMU and Debug architecture, so we > > > constrain these fields to supported values. > > > > > > Since KVM now correctly handles CP15 and CP10 register traps, we no > > > longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead > > > emulate reads with their safe values. > > > > > > Signed-off-by: Oliver Upton <oupton@xxxxxxxxxx> > > > > Reviewed-by: Reiji Watanabe <reijiw@xxxxxxxxxx> > > > > BTW, due to this, on a system that supports PMUv3, ID_DFR0_E1 value will > > become 0 for the aarch32 guest without PMUv3. This is the correct behavior, > > but it affects migration. I'm not sure how much we should care about > > migration of the aarch32 guest though (and it will be resolved once ID > > registers become configurable anyway). > > I believe userspace has been accessing the sanitised values of these > feature registers the entire time, so we should be OK on the UAPI side. You are right:) I totally forgot this was just about trapping. Sorry for the noise. Thanks, Reiji
