Re: [PATCH] xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch

[Julien Grall <julien@xxxxxxx>]

Hi Bertrand,

On 18/08/2020 10:25, Bertrand Marquis wrote:
> > > diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
> > > index 674beb0353..588089e5ae 100644
> > > --- a/xen/include/asm-arm/cpufeature.h
> > > +++ b/xen/include/asm-arm/cpufeature.h
> > > @@ -13,8 +13,8 @@
> > > #define cpu_has_el2_64    (boot_cpu_feature64(el2) >= 1)
> > > #define cpu_has_el3_32    (boot_cpu_feature64(el3) == 2)
> > > #define cpu_has_el3_64    (boot_cpu_feature64(el3) >= 1)
> > > -#define cpu_has_fp        (boot_cpu_feature64(fp) == 0)
> > > -#define cpu_has_simd      (boot_cpu_feature64(simd) == 0)
> > > +#define cpu_has_fp        (boot_cpu_feature64(fp) <= 1)
> > > +#define cpu_has_simd      (boot_cpu_feature64(simd) <= 1)
> > But this is only good until the next feature bump. I think we should be
> > more future-proof here. The architecture describes those two fields as
> > "signed"[1], and guarantees that "if value >= 0" is a valid test for the
> > feature. Which means we are good as long as the sign bit (bit 3) is
> > clear, which translates into:
> > #define cpu_has_fp        (boot_cpu_feature64(fp) < 8)
> > Same for simd.
> We cannot really be sure that a new version introduced will require the
> same context save/restore so it might dangerous to claim we support
> something we have no idea about.
Right. However, if we don't do anything for those values, it may be 
possible to see corruption again when it gets bumped.
If we are concerned about incompatibility, then we should start checking 
the features and only allow boot with what we know.
Cheers,

--
Julien Grall