Re: Next features and target for development

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

>> Are you suggesting that comparing the flags would yield a false
>> positive?

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

Attachment: pgpI7sA3J5rMl.pgp
Description: PGP signature

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]