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

[Dor Laor <dlaor@redhat.com>]

On 01/07/2010 03:14 PM, Anthony Liguori wrote:
> 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.

It solves controlling the destination qemu execution all right but does 
not change the initial spawning of the original guest - to know whether 
,-syscall is needed or not.

Anyway, I'm in favor of it too.

>>
>> 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
>