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? In that case, I'm fine with merging this patch. -Christoffer -- 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
