On 16 December 2013 23:39, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote:
> On Thu, Nov 28, 2013 at 01:33:18PM +0000, Peter Maydell wrote:
>> + ahcc->target = init.target;
>> + ahcc->dtb_compatible = "arm,arm-v7";
>
> arm,arm-v8 ?
Oops, yes, cut-n-pasto.
>
>> +
>> + kvm_arm_destroy_scratch_host_vcpu(fdarray);
>> +
>> + /* We can assume any KVM supporting CPU is at least a v8
>> + * with VFPv4+Neon; this in turn implies most of the other
>> + * feature bits.
>
> not sure I understand the bit about implying other feature bits, the
> only other thing we're setting here is AARCH64 and the features bits are
> enum values?
target-arm/cpu.c:cpu_realize_fn() has a large set of if statements
like
if (arm_feature(env, ARM_FEATURE_V8)) {
set_feature(env, ARM_FEATURE_V7);
set_feature(env, ARM_FEATURE_ARM_DIV);
set_feature(env, ARM_FEATURE_LPAE);
}
because architecturally some features or arch versions imply
that you have others (eg above v8 means we always know
we have LPAE and division)...
>> + */
>> + set_feature(&features, ARM_FEATURE_V8);
>> + set_feature(&features, ARM_FEATURE_VFP4);
>> + set_feature(&features, ARM_FEATURE_NEON);
>> + set_feature(&features, ARM_FEATURE_AARCH64);
...and because presence of the 'v8', 'vfp4', 'neon' features implies
(as enforced via those if statements) presence of just about every
other feature it means we don't need to have specific
tests for "do the CPU's feature registers say we support
division?" like the v7 KVM code does, because we know
that it's all implied automatically.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
