On 09/12/2010 04:30 PM, Joerg Roedel wrote:
Either way, I don't think we need a phenom2 type. The features
additional are minor enough to not really matter and all use cases I
can come up with require either -cpu host (local virt) or -cpu phenom
(migration).
I'm fine with this (or with adding phenom2). But don't make phenom
contain flags that real phenoms don't have.
How about features that are not supported by the hardware but can be
supported in emulation? The VMCBCLEAN feature is one of those which
makes a lot of sense to reduce the emulated world-switch times. I guess
its ok to enable those with -cpu host?
It's a good question. We do that with x2apic, so yes.
Userspace can do four things with KVM_GET_SUPPORTED_CPUID:
- feed it right back to KVM_SET_CPUID2, getting maximum features and
hopefully performance
- use it to mask the real cpuid which it fetches directly, getting
something as similar as possible to the host
- use it to mask a predefined cpu type, getting something as similar as
possible to that cpu type
- use it to verify that a predefined cpu type is supported, getting
somthing exactly the same as that cpu type
-cpu host is the first option. If the need comes for the second option,
we can provide it.
I'll note that KVM_GET_SUPPORTED_CPUID can return values not present in
the host cpuid in the documentation.
--
error compiling committee.c: too many arguments to function
--
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
