[Libvir] Re: Next features and target for development

AL> Okay, flags is a subset of the common cpuid features. This is not by AL> any means exhaustive of the features supported by a particular CPU but AL> it is a reasonable starting point. Right, ok. AL> No, it may be safe. Consider the case where you're migrating from a AL> core duo to a core solo. This is the same chip with a few things AL> disabled including VT which will manifest as a lack of the "vmx" AL> flag. In this case, it's 100% safe to do the migration because a PV AL> guest cannot use that CPU feature. Sure. So the Xen implementation of this check would know which flags it could safely ignore, such as "vmx". AL> Something a bit more tricky is the sse2 flag. Do most VMs really use AL> sse2? If no application in your VM is using sse2, then you should be AL> able to migrate from across CPUs that do not support sse2 right? But, since we don't know that, we would return "false", indicating that it's not definitely safe. Whether it would work or not, or if it's worth trying or not is something that may be specific to a higher-level tool or system. AL> IMHO, this is not a decision you want to take away from an AL> administrator. Guiding them and helping them make an informed AL> decision is not a bad idea but just having a blind boolean isn't AL> going to be all that helpful. All I'm suggesting here is a function that returns a boolean based on completely safe tests. I'm not saying that a migration function should refuse to run if this test is false. In this case, it seems sane for something like virt-manager to pop up a box to the user that says something like: "This is not likely to work based on some processor compatibility checks. Do you want to continue anyway?" AL> Yes. Meaning that a flags check would indicate compatibility where there is none? Do you have an example? AL> KVM guests all (in theory) expose a least-common subset of processor AL> features unless explicitly told to expose something that's specific to AL> a processor. Because of this, you can migrate not just across AL> processor families but from Intel to AMD and vice versa. Which is something that the qemu implementation of this check could test for and act intelligently, right? AL> Something that compared systems, and provided specific information AL> about potential incompatibilities would be useful. Then a higher AL> level piece of software could pick and choose what it cared about. A AL> boolean interface is only going to have one happy consumer and that's AL> going to be whoever decides what the policy should be :-) That's probably true. If the test can return "definitely compatible" or "maybe not compatible", I think it's worth having. Perhaps the test could return more granular information and the yes/no (or several levels of such) could be macros? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms(a)us.ibm.com