| Message ID | 1250804057-29681-1-git-send-email-andre.przywara@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Andre Przywara wrote: > In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, > which is the least common denominator of all KVM-capable x86-CPUs > (based on Intel Pentium 4 Prescott). It can be used as a base type > for migration. The idea is nice and the name is right, but the description is wrong. It obviously isn't the least common denominator of all KVM-capable x86-CPUs, as my KVM-capable Core Duo (32-bit) cannot run it. A kvm32 would be nice for symmetry. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jamie Lokier wrote: > Andre Przywara wrote: >> In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, >> which is the least common denominator of all KVM-capable x86-CPUs >> (based on Intel Pentium 4 Prescott). It can be used as a base type >> for migration. > > The idea is nice and the name is right, but the description is wrong. > > It obviously isn't the least common denominator of all KVM-capable > x86-CPUs, as my KVM-capable Core Duo (32-bit) cannot run it. > A kvm32 would be nice for symmetry. Well, thats why I named it kvm_64_. If you happen to stuck with 32bit (pity you!) then I agree that a kvm32 would be nice to have. Will think about it... Regards, Andre.
On 08/21/2009 12:34 AM, Andre Przywara wrote: > In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, > which is the least common denominator of all KVM-capable x86-CPUs > (based on Intel Pentium 4 Prescott). It can be used as a base type > for migration. > Typically users will want more specialized greatest common denomiator cpu types; if a site has standardized on recent hardware they will want the features of that hardware exposed. I think this is best left to management software, which has more information about the migration pool.
On Fri, Aug 21, 2009 at 12:41 PM, Avi Kivity<avi@redhat.com> wrote: > On 08/21/2009 12:34 AM, Andre Przywara wrote: >> >> In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, >> which is the least common denominator of all KVM-capable x86-CPUs >> (based on Intel Pentium 4 Prescott). It can be used as a base type >> for migration. >> > > Typically users will want more specialized greatest common denomiator cpu > types; if a site has standardized on recent hardware they will want the > features of that hardware exposed. > > I think this is best left to management software, which has more information > about the migration pool. I believe what we want is an automatic tool that will connect to a list of machines, and determine which qemu cpu type we should use. Doesn't sound like black magic... > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html >
Glauber Costa wrote: > On Fri, Aug 21, 2009 at 12:41 PM, Avi Kivity<avi@redhat.com> wrote: >> On 08/21/2009 12:34 AM, Andre Przywara wrote: >>> In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, >>> which is the least common denominator of all KVM-capable x86-CPUs >>> (based on Intel Pentium 4 Prescott). It can be used as a base type >>> for migration. >>> >> Typically users will want more specialized greatest common denomiator cpu >> types; if a site has standardized on recent hardware they will want the >> features of that hardware exposed. >> >> I think this is best left to management software, which has more information >> about the migration pool. > I believe what we want is an automatic tool that will connect to a > list of machines,and determine which qemu cpu type we should use. > Doesn't sound like black magic... I already have such a basic tool. It uses ssh (with pubkey) to connect to the target machine, then uses dd on /dev/cpu/0/cpuid to get the CPUID info. This requires cpuid.ko to be loaded and the permissions on the device file to be sufficient (the appropriate udev patch is already upstream). It then computes the least common denominator bits from several machines. Were you thinking of that approach or do you want to include this host CPUID functionality into QEMU (somehow embedded in the migration handler)? Regards, Andre.
Avi Kivity wrote: > On 08/21/2009 12:34 AM, Andre Przywara wrote: >> In addition to the TCG based qemu64 type let's introduce a kvm64 CPU >> type, >> which is the least common denominator of all KVM-capable x86-CPUs >> (based on Intel Pentium 4 Prescott). It can be used as a base type >> for migration. >> > Typically users will want more specialized greatest common denomiator > cpu types; if a site has standardized on recent hardware they will want > the features of that hardware exposed. Sure, but this was not the purpose of this patch. Currently KVM guests see a CPU type which is TCG dependent, so I just wanted to get rid of this. Features of TCG and features of the host processor are totally uncorrelated. This new type should be KVM's default, leaving -cpu host as the alternative for the non-migration case. > I think this is best left to management software, which has more > information about the migration pool. Sure. Regards, Andre.
Avi Kivity wrote: > On 08/21/2009 12:34 AM, Andre Przywara wrote: > >In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, > >which is the least common denominator of all KVM-capable x86-CPUs > >(based on Intel Pentium 4 Prescott). It can be used as a base type > >for migration. > > > > Typically users will want more specialized greatest common denomiator > cpu types; if a site has standardized on recent hardware they will want > the features of that hardware exposed. My experience is of sites which don't standardise on hardware in that way. They standardise on suppliers, and buy whatever is available when more hardware is needed, or reuse existing hardware which is made redundant from some other purpose. kvm64 is a good compromise for sites like that, because it should work with everything that's 64-bit and capable of running KVM. I expect all "server" machines which can run KVM are 64-bit, and it's only laptops which have 32-bit KVM-capable chips (but I'm not sure). -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Andre Przywara wrote: > If you happen to stuck with 32bit > (pity you!) then I agree that a kvm32 would be nice to have. > Will think about it... I know that 32-bit is a bit slower for some things due to register pressure (but it's a bit faster for some things due to less memory needed for pointers), and it's RAM is limited to about 3GB in practice, which affects some things but is plenty for others. I know it's a pain for KVM developers to support 32-bit hosts. And yes, it would be nice to run a 64-bit guest from time to time. But apart from being a bit slower, is there anything wrong with 32-bit x86s compared with 64-bit that justifies pity? The 32-bitness doesn't seem to be a handicap, only perhaps the expected amount of slowness for a laptop that's 2-3 years old, or a current netbook, compared with current desktops and servers. So I'm having a hard time understanding why 32-bitness is considered bad for KVM - why "pity"? Does it have any other real problems than not being able to emulate 64-bit guests that I should know about, or is it just a matter of distaste? -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/22/2009 12:53 AM, Andre Przywara wrote: >>> I think this is best left to management software, which has more >>> information >>> about the migration pool. >> I believe what we want is an automatic tool that will connect to a >> list of machines,and determine which qemu cpu type we should use. > > > Doesn't sound like black magic... > I already have such a basic tool. It uses ssh (with pubkey) to connect > to the target machine, then uses dd on /dev/cpu/0/cpuid to get the > CPUID info. This requires cpuid.ko to be loaded and the permissions on > the device file to be sufficient (the appropriate udev patch is > already upstream). It then computes the least common denominator bits > from several machines. > Were you thinking of that approach or do you want to include this host > CPUID functionality into QEMU (somehow embedded in the migration > handler)? When qemu is involved it is already far too late. This node needs to be classified when it is added to the cluster. But maybe we can integrate it into 'qemu -capabilities', if and when that is added.
On 08/22/2009 12:59 AM, Andre Przywara wrote: >> Typically users will want more specialized greatest common denomiator >> cpu types; if a site has standardized on recent hardware they will >> want the features of that hardware exposed. > Sure, but this was not the purpose of this patch. Currently KVM guests > see a CPU type which is TCG dependent, so I just wanted to get rid of > this. Features of TCG and features of the host processor are totally > uncorrelated. This new type should be KVM's default, leaving -cpu host > as the alternative for the non-migration case. That does make sense. Note we can call it '-cpu kvm' since qemu will strip away long mode if it is not supported by the cpu or by the kernel.
Avi Kivity wrote: > On 08/22/2009 12:59 AM, Andre Przywara wrote: > >>Typically users will want more specialized greatest common denomiator > >>cpu types; if a site has standardized on recent hardware they will > >>want the features of that hardware exposed. > >Sure, but this was not the purpose of this patch. Currently KVM guests > >see a CPU type which is TCG dependent, so I just wanted to get rid of > >this. Features of TCG and features of the host processor are totally > >uncorrelated. This new type should be KVM's default, leaving -cpu host > >as the alternative for the non-migration case. > > That does make sense. Note we can call it '-cpu kvm' since qemu will > strip away long mode if it is not supported by the cpu or by the kernel. I thought the point was to provide a "lowest common denominator" for migration, while acknowledging that 64-bit is too useful to exclude? So if you start running on a 64-bit host, but know you have 32-bit hosts in your pool, you'll need '-cpu kvm32'. And if you start on a 32-bit host, but want to migrate to a 64-bit host, will that work if the destination has different cpuid than the source? -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On (Fri) Aug 21 2009 [23:53:41], Andre Przywara wrote: > Glauber Costa wrote: >> On Fri, Aug 21, 2009 at 12:41 PM, Avi Kivity<avi@redhat.com> wrote: >>> On 08/21/2009 12:34 AM, Andre Przywara wrote: >>>> In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, >>>> which is the least common denominator of all KVM-capable x86-CPUs >>>> (based on Intel Pentium 4 Prescott). It can be used as a base type >>>> for migration. >>>> >>> Typically users will want more specialized greatest common denomiator cpu >>> types; if a site has standardized on recent hardware they will want the >>> features of that hardware exposed. >>> >>> I think this is best left to management software, which has more information >>> about the migration pool. >> I believe what we want is an automatic tool that will connect to a >> list of machines,and determine which qemu cpu type we should use. > > Doesn't sound like black magic... > I already have such a basic tool. It uses ssh (with pubkey) to connect > to the target machine, then uses dd on /dev/cpu/0/cpuid to get the CPUID > info. This requires cpuid.ko to be loaded and the permissions on the > device file to be sufficient (the appropriate udev patch is already > upstream). It then computes the least common denominator bits from > several machines. I had such patches as well. I think I sent them on qemu-devel. When do you plan on sending your patches out? Amit -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/target-i386/helper.c b/target-i386/helper.c index dd89885..4cf62d9 100644 --- a/target-i386/helper.c +++ b/target-i386/helper.c @@ -187,6 +187,32 @@ static x86_def_t x86_defs[] = { .xlevel = 0x80000008, .model_id = "Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz", }, + { + .name = "kvm64", + .level = 5, + .vendor1 = CPUID_VENDOR_INTEL_1, + .vendor2 = CPUID_VENDOR_INTEL_2, + .vendor3 = CPUID_VENDOR_INTEL_3, + .family = 15, + .model = 6, + .stepping = 1, + /* Missing: CPUID_VME, CPUID_HT */ + .features = PPRO_FEATURES | + CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | + CPUID_PSE36, + /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */ + .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16, + /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */ + .ext2_features = (PPRO_FEATURES & 0x0183F3FF) | + CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, + /* Missing: CPUID_EXT3_LAHF_LM, CPUID_EXT3_CMP_LEG, CPUID_EXT3_EXTAPIC, + CPUID_EXT3_CR8LEG, CPUID_EXT3_ABM, CPUID_EXT3_SSE4A, + CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH, + CPUID_EXT3_OSVW, CPUID_EXT3_IBS, CPUID_EXT3_SVM */ + .ext3_features = 0, + .xlevel = 0x80000008, + .model_id = "Common KVM processor" + }, #endif { .name = "qemu32",
In addition to the TCG based qemu64 type let's introduce a kvm64 CPU type, which is the least common denominator of all KVM-capable x86-CPUs (based on Intel Pentium 4 Prescott). It can be used as a base type for migration. Signed-off-by: Andre Przywara <andre.przywara@amd.com> --- target-i386/helper.c | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-)