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

[Marc Zyngier]

On 17/07/15 10:33, Christoffer Dall wrote:
> 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 at 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?

The jury is still out on that one.

I was initially not going to enforce anything (after all, this isn't
that different from the whole CNTVOFF story where we allow userspace to
shoot itself in the foot), but I'm equally happy to make MIDR_EL1
read-only if we're creating a generic guest...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...