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

[Chalamarla, Tirumalesh]

> On Jul 17, 2015, at 3:19 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> 
> On 17/07/15 11:15, Christoffer Dall wrote:
>> On Fri, Jul 17, 2015 at 10:56:39AM +0100, Marc Zyngier wrote:
>>> 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...
>>> 
>> Looking at the code, midr_el1 is already an invariant register, so isn't
>> this automagically enforced already?
> 
> Ah, you're perfectly right, I has already in that fantasy world where we
> can actually migrate VMs across implementations.
> 
>> In that case, I'm fine with merging this patch.
> 
> Cool. I'll queue that for 4.3.
> 

this sounds nice. 
> Thanks,
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny...