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