Patchwork introduce kvm64 CPU

login
register
mail settings
Submitter Andre Przywara
Date Aug. 20, 2009, 9:34 p.m.
Message ID <1250804057-29681-1-git-send-email-andre.przywara@amd.com>
Download mbox | patch
Permalink /patch/31779/
State Superseded
Headers show

Comments

Andre Przywara - Aug. 20, 2009, 9:34 p.m.
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(-)
Jamie Lokier - Aug. 21, 2009, 1:33 p.m.
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
Andre Przywara - Aug. 21, 2009, 2:23 p.m.
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.
Avi Kivity - Aug. 21, 2009, 3:41 p.m.
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.
Glauber Costa - Aug. 21, 2009, 4:01 p.m.
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
>
Andre Przywara - Aug. 21, 2009, 9:53 p.m.
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.
Andre Przywara - Aug. 21, 2009, 9:59 p.m.
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.
Jamie Lokier - Aug. 22, 2009, 1:03 a.m.
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
Jamie Lokier - Aug. 22, 2009, 1:45 a.m.
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
Avi Kivity - Aug. 23, 2009, 9:03 a.m.
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.
Avi Kivity - Aug. 23, 2009, 9:05 a.m.
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.
Jamie Lokier - Aug. 23, 2009, 12:47 p.m.
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
Amit Shah - Aug. 23, 2009, 1:20 p.m.
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

Patch

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