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

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

 



On 01/07/2010 01:59 PM, Avi Kivity wrote:
On 01/07/2010 11:40 AM, Dor Laor wrote:
There's no such thing as Nehalem.


Intel were ok with it. Again, you can name is corei7 or
xeon34234234234, I don't care, the principle remains the same.


There are several processors belonging to the Nehalem family and each
have different features.

We can start with the older one, and once it get's that important add the newer ones. Until that happens users can either use -host or have nehalem,+sse4_2,+newFeature



What's not simple about the above 4 options?

If a qemu/kvm/processor combo doesn't support a feature (say, nx) we
have to remove it from the migration pool even if the Nehalem processor
class says it's included. Or else not admit that combination into the
migration pool in the first place.

It still management role to compute least common denominator for live migration sets.

btw: for nx disabled bios, we should just ignore it from product. Qemu direct users should add ,-nx


What's a better alternative (that insures users understand it and use
it and guest msi and even skype application is happy about it)?


Have management scan new nodes and classify them.


Of course. Just don't let management control stepping automatically, it should only be made for very advanced users and only manually.
--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux