On Fri, Apr 25, 2014 at 12:57:48AM +0200, Paolo Bonzini wrote: > Il 24/04/2014 22:57, Eduardo Habkost ha scritto: > >On Thu, Apr 24, 2014 at 04:42:33PM -0400, Paolo Bonzini wrote: > >>Il 22/04/2014 21:14, Eduardo Habkost ha scritto: > >>>Not for "-cpu host". If somebody needs migration to work, they shouldn't > >>>be using "-cpu host" anyway (I don't know if you have seen the other > >>>comments in my message?). > >> > >>I'm not entirely sure. If you have hosts with exactly identical > >>chipsets, "-cpu host" migration will in all likelihood work. > >>Marcelo's approach is safer. > > > >If that didn't break other use cases, I would agree. > > > >But "-cpu host" today covers two use cases: 1) enabling everything that > >can be enabled, even if it breaks migration; 2) enabling all stuff that > >can be safely enabled without breaking migration. > > What does it enable *now* that breaks migration? Every single feature it enables can break it. It breaks if you upgrade to a QEMU version with new feature words. It breaks if you upgrade to a kernel which supports new features. A feature that doesn't let you upgrade the kernel isn't a feature I expect users to be relying upon. libvirt even blocks migration if "-cpu host" is in use. > > >Now we can't do both at the same time[1]. > > > >(1) is important for management software; > >(2) works only if you are lucky. > > Or if you plan ahead. With additional logic even invariant TSC in > principle can be made to work across migration if the host clocks are > synchronized well enough (PTP accuracy is in the 100-1000 TSC ticks > range). Yes, it is possible in the future. But we never planned for it, so "-cpu host" never supported migration. > > >Why would it make sense to break (1) to try make (2) work? > > > >[1] I would even argue that we never did both at the same time."-cpu > >host" depends on host hardware capabilities, host kernel capabilities, > >and host QEMU version (we never took care of keeping guest ABI with > >"-cpu host"). If migration did work, it was never supposed to. > > I think this is where I disagree. Migration of the PMU is one thing > that obviously was done with "-cpu host" in mind. We may try to make a reliable implementation of use case (2) some day, yes. But the choice I see right now is between trying not break a feature that was never declared to exist, or breaking an existing interface that is required to solve existing bugs between libvirt and QEMU. -- Eduardo -- 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
