On Tue, Dec 17, 2013 at 12:21:27AM +0000, Peter Maydell wrote:
> 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.
>
Got it, I was looking for something like that, but somehow missed the
realize function. Thanks!
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
