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@xxxxxxx> 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. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
