[PATCH] arm64/kvm: Add generic v8 KVM target

[christoffer.dall@linaro.org (Christoffer Dall)]

On Fri, Jul 03, 2015 at 11:10:09AM +0100, Marc Zyngier wrote:
> On 03/07/15 10:34, Peter Maydell wrote:
> > On 3 July 2015 at 09:28, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >> On 03/07/15 09:12, Peter Maydell wrote:
> >>> I would still like to see the proponents of this patch say
> >>> what their model is for userspace support of cross-host migration,
> >>> if we're abandoning the model the current API envisages.
> >>
> >> I thought we had discussed this above, and don't really see this as a
> >> departure from the current model:
> >>
> >> - "-cpu host" results in "GENERIC" being used: VM can only be migrated
> >> to the exact same HW (no cross-host migration). MIDR should probably
> >> become RO.
> >> - "-cpu host" results in "A57" (for example): VM can be migrated to a
> >> variety of A57 platforms, and allow for some fuzzing on the revision (or
> >> accept any revision).
> >> - "-cpu a57" forces an A57 model to be emulated, always. It is always
> >> possible to migrate such a VM on any host.
> >>
> >> I think only the first point is new, but the last two are what we have
> >> (or what we should have).
> > 
> > Right, but the implicit idea of this GENERIC patch seems to
> > be that new host CPU types don't get their own KVM_ARM_TARGET_*
> > constant, and are thus forever unable to do cross-host migration.
> > It's not clear to me why we'd want to have new CPUs be second
> > class citizens like that.
> 
> I certainly don't want to see *any* CPU be a second class citizen. But
> let's face it, we're adding more and more targets that don't implement
> anything new, and just satisfy themselves with the generic implementation.
> 
> I see it as an incentive to provide something useful (tables of all the
> registers with default values?) so that cross-host migration becomes a
> reality instead of the figment of our imagination (as it is now). If it
> wasn't already ABI, I'd have removed the existing targets until we have
> something meaningful to put there.

What we're doing now certainly seems silly, because we're adding kernel
patches without bringing anything to the table...

> 
> Now, I also have my own doubts about cross-host migration (timers
> anyone?). But I don't see the above as a change in policy. More as a way
> to outline the fact that we currently don't have the right level of
> information/infrastructure to support it at all.
> 
The one thing that I've lost track of here (sorry) is whether we're
enforcing the inability to do cross-host migration with the generic
target when this patch is merged or do we leave this up to the graces of
userspace?

Thanks,
-Christoffer