Peter Maydell <peter.mayd...@linaro.org> writes: > On 8 February 2018 at 17:31, Alex Bennée <alex.ben...@linaro.org> wrote: >> While for CONFIG_USER_ONLY it is policy for the "cpu" to be the most >> capable is can be this does cause problems. For example legacy RISU >> runs would fail as there are a bunch of implemented instructions which >> would have caused failures that now trigger actual calculations. >> >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > >> static void aarch64_cpu_initfn(Object *obj) >> { >> object_property_add_bool(obj, "aarch64", aarch64_cpu_get_aarch64, >> @@ -283,6 +303,13 @@ static void aarch64_cpu_initfn(Object *obj) >> "Set on/off to enable/disable aarch64 " >> "execution state ", >> NULL); >> +#ifdef CONFIG_USER_ONLY >> + object_property_add_bool(obj, "fp16", aarch64_cpu_get_fp16, >> + aarch64_cpu_set_fp16, NULL); >> + object_property_set_description(obj, "fp16", >> + "Set on/off to enable/disable FP16 >> extensions ", >> + NULL); >> +#endif >> } > > Good news everybody -- this is an opportunity for a naming bikeshed > discussion!
Everyone's favourite kind of discussion ;-) > The property names we use here are effectively ABI because they'll > be available to the user on the command line, so we want to get the > right names. This is the first of these, but we can reasonably > assume we'll have more feature switches in the future for various > other optional instruction set extensions. > > There are two obvious choices here: > * use the architecture extension names from the Arm ARM A1.7.4 > (in this case that's "ARMv8.2-FP16", which we could reasonably > abbreviate to fp16) So since I last tested this stuff I noticed upstream broke my RISU testing with the addition of the crypto instructions. The reason being the RISU test set does exercise UNDEF's which get used in later revs. However I realised I could use -cpu cortex-a57 to achieve the same thing and avoid enabling features for later specs. Maybe it would be simpler just to add cpu types for the baseline architecture profiles? -cpu armv8.0 -cpu armv8.1 -cpu armv8.2 Defaulting of course to the most capable CPU type for linux-user. That said FP16 is an optional feature so it is perfectly legitimate to have: -cpu armv8.2+fp16 In fact the manual goes further in allowing any v8.x+1 feature to be snarfed into a v8.x confirming CPU. That said *my* use case is turning features off, maybe that is enough to expose a plain v8.0 on the command line for now until someone comes up with a useful for case for building these franken-CPUs? > * use the hwcaps names that Linux defines and prints in /proc/cpuinfo > (in this case that would be a combination of "fphp" and "asimdhp", > since hwcaps reflects the ID register setup that allows a CPU > to report support for one and not the other) In naming I favour the Arm ARM over whatever Linux-ism /proc came up with. > > Whatever we do, we should have a comment describing our naming > conventions, so we can follow it next time we add one of these... > > thanks > -- PMM -- Alex Bennée