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
