On Mon, 26 Aug 2019 at 09:38, Christoffer Dall <christoffer.dall@xxxxxxx> wrote:
> On Sun, Jun 30, 2019 at 12:18:59PM +0200, Jan Kiszka wrote:
> > Hmm, looking at what KVM_ARM_TARGET_CORTEX_A7 and ..._A15 differentiates, I
> > found nothing so far:
> >
> > kvm_reset_vcpu:
> > switch (vcpu->arch.target) {
> > case KVM_ARM_TARGET_CORTEX_A7:
> > case KVM_ARM_TARGET_CORTEX_A15:
> > reset_regs = &cortexa_regs_reset;
> > vcpu->arch.midr = read_cpuid_id();
> > break;
> >
> > And arch/arm/kvm/coproc_a15.c looks like a copy of coproc_a7.c, just with some
> > symbols renamed.
> >
> > What's the purpose of all that? Planned for something bigger but never
> > implemented? From that perspective, there seems to be no need to arch.target and
> > kvm_coproc_target_table at all.
> >
>
> There was some speculation involved here, and we needed to figure out
> how we would deal with implementation defined behavior, so we built this
> support for each type of CPU etc.
>
> In reality, most CPUs that we support are pretty similar and that's why
> we did the generic CPU type instead. In practice, there might be a more
> light-weight appraoch to handling the minor differences between CPU
> implementations than what we have here.
The other future-direction I think we were thinking about was that
one day we'd want to support showing the guest a CPU other than
what the host is, at which point you would want to be able to
say specifically "give me a Cortex-A7" and have it work even if the
host was a Cortex-A15. But there are significant unresolved design
issues if we ever did want to go in that direction...
thanks
-- PMM
