Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

[Anthony Liguori]

On 01/07/2010 06:40 AM, Avi Kivity wrote:
> On 01/07/2010 02:33 PM, Anthony Liguori wrote:
> > There's another option.
> >
> > Make cpuid information part of live migration protocol, and then 
> > support something like -cpu Xeon-3550.  We would remember the exact 
> > cpuid mask we present to the guest and then we could validate that we 
> > can obtain the same mask on the destination.
>
> Currently, our policy is to only migrate dynamic (from the guest's 
> point of view) state, and specify static state on the command line [1].
>
> I think your suggestion makes a lot of sense, but I'd like to expand 
> it to move all guest state, whether dynamic or static.  So '-m 1G' 
> would be migrated as well (but not -mem-path).  Similarly, in -drive 
> file=...,if=ide,index=1, everything but file=... would be migrated.

Yes, I agree with this and it should be in the form of an fdt.  This 
means we need full qdev conversion.

But I think cpuid is somewhere in the middle with respect to static vs. 
dynamic.  For instance, -cpu host is very dynamic in that you get very 
difficult results on different systems.  Likewise, because of kvm 
filtering, even -cpu qemu64 can be dynamic.

So if we didn't have filtering and -cpu host, I'd agree that it's 
totally static but I think in the current state, it's dynamic.

> This has an advantage wrt hotplug: since qemu is responsible for 
> migrating all guest visible information, the migrator is no longer 
> responsible for replaying hotplug events in the exact sequence they 
> happened.

Yup, 100% in agreement as a long term goal.

> In short, I think we should apply your suggestion as broadly as possible.
>
> [1] cpuid state is actually dynamic; repeated cpuid instruction 
> execution with the same operands can return different results.  kvm 
> supports querying and setting this state.

Yes, and we save some cpuid state in cpu.  We just don't save all of it.

Regards,

Anthony Liguori