Re: [Qemu-devel] [patch 2/2] target-i386: block migration and savevm if invariant tsc is exposed

[Eduardo Habkost]

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