> On Jul 17, 2015, at 3:19 AM, Marc Zyngier <marc.zyngier@xxxxxxx> 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@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. > this sounds nice. > 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
