[PATCH] Match virtual machine processor vendor to that of the host

[PATCH] Match virtual machine processor vendor to that of the host

[Jeremy Katz]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Currently, kvm ends up just using the standard qemu cpu initialization.
This means that all x86_64 virtual machines appear to have an
AuthenticAMD (AMD64) processor.  This ends up causing a problem when
booting some x86_64 Linux kernels as they attempt to do AMD64 specific
initialization for things like performance counters.  Since those MSRs
aren't supported on the Intel host, the virtual machine is halted.

The attached patch makes it so that we check the actual cpu type of the
host and then provide the same cpu type for the virtual machine.

Jeremy

[-- Attachment #2: kvm-cputype.patch --]
[-- Type: text/x-patch, Size: 2294 bytes --]

Index: qemu/exec-all.h
===================================================================
--- qemu/exec-all.h	(revision 4142)
+++ qemu/exec-all.h	(working copy)
@@ -603,3 +603,7 @@
 }
 
 #endif
+
+#ifdef USE_KVM
+#include "qemu-kvm.h"
+#endif
--- qemu/target-i386/helper2.c	(revision 4142)
+++ qemu/target-i386/helper2.c	(working copy)
@@ -141,6 +141,9 @@
 #ifdef USE_KQEMU
     kqemu_init(env);
 #endif
+#ifdef USE_KVM
+    kvm_cpu_init(env);
+#endif
     return env;
 }
 
--- qemu/qemu-kvm.c	(revision 4142)
+++ qemu/qemu-kvm.c	(working copy)
@@ -590,6 +590,56 @@
     .io_window = kvm_io_window,
 };
 
+static inline unsigned int cpuid_ebx(unsigned int op)
+{
+    unsigned int eax, ebx;
+    __asm__ volatile
+	("movl %%ebx, %%esi\n\t"
+         "cpuid\n\t"
+         "xchgl %%ebx, %%esi"
+         : "=a" (eax), "=S" (ebx)
+         : "0" (op));
+    return ebx;
+}
+
+static void kvm_update_cpuid(CPUState *env)
+{
+    int family, model, stepping;
+
+    /* we need to differentiate intel vs amd processors here.  
+     * FIXME: should match more cpuid capabilities here */
+    switch (cpuid_ebx(0)) {
+    case 0x756e6547: /* Intel */
+        env->cpuid_vendor1 = 0x756e6547; /* "Genu" */
+        env->cpuid_vendor2 = 0x49656e69; /* "ineI" */
+        env->cpuid_vendor3 = 0x6c65746e; /* "ntel" */
+        family = 6;
+        model = 15;
+        stepping = 3;
+        break;
+    case 0x68747541: /* AMD */
+        env->cpuid_vendor1 = 0x68747541; /* "Auth" */
+        env->cpuid_vendor2 = 0x69746e65; /* "enti" */
+        env->cpuid_vendor3 = 0x444d4163; /* "cAMD" */
+        family = 6;
+        model = 2;
+        stepping = 3;
+        break;
+    default:
+        /* we don't know what it is, just return */
+        return;
+        break;
+    }
+
+    env->cpuid_version = (family << 8) | (model << 4) | stepping;
+}
+
+int kvm_cpu_init(CPUState *env)
+{
+    kvm_update_cpuid(env);
+    return 0;
+}
+
 int kvm_qemu_init()
 {
     /* Try to initialize kvm */
 
Index: qemu/qemu-kvm.h
===================================================================
--- qemu/qemu-kvm.h	(revision 4142)
+++ qemu/qemu-kvm.h	(working copy)
@@ -10,4 +10,6 @@
 int kvm_cpu_exec(CPUState *env);
 int kvm_update_debugger(CPUState *env);
 
+int kvm_cpu_init(CPUState *env);
+
 #endif

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Avi Kivity]

Jeremy Katz wrote:
> Currently, kvm ends up just using the standard qemu cpu initialization.
> This means that all x86_64 virtual machines appear to have an
> AuthenticAMD (AMD64) processor.  This ends up causing a problem when
> booting some x86_64 Linux kernels as they attempt to do AMD64 specific
> initialization for things like performance counters.  Since those MSRs
> aren't supported on the Intel host, the virtual machine is halted.
>
> The attached patch makes it so that we check the actual cpu type of the
> host and then provide the same cpu type for the virtual machine.
>
>   

Windows crashes immediately with this patch (STOP: 0x7E (0xc0000005 
0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode 
BSODs), so either it's doing too much or not enough.

Note that we support migration from Intel to AMD and vice versa, so it 
would be good to supply a command line parameter to set the cpuid (to a 
least common denominator CPU).


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Michael Riepe]

Hi!

Avi Kivity wrote:

> Windows crashes immediately with this patch (STOP: 0x7E (0xc0000005 
> 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode 
> BSODs), so either it's doing too much or not enough.
> 
> Note that we support migration from Intel to AMD and vice versa, so it 
> would be good to supply a command line parameter to set the cpuid (to a 
> least common denominator CPU).

That would be extremely important for live migration. I doubt that any
current OS - even those that support CPU hot-plugging - will allow you
to replace an AMD CPU with an Intel model (or vice versa) on the fly.

-- 
Michael "Tired" Riepe <michael-0QoEqw4nQxo@public.gmane.org>
X-Tired: Each morning I get up I die a little

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Jeremy Katz]

On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote:
> Jeremy Katz wrote:
> > Currently, kvm ends up just using the standard qemu cpu initialization.
> > This means that all x86_64 virtual machines appear to have an
> > AuthenticAMD (AMD64) processor.  This ends up causing a problem when
> > booting some x86_64 Linux kernels as they attempt to do AMD64 specific
> > initialization for things like performance counters.  Since those MSRs
> > aren't supported on the Intel host, the virtual machine is halted.
> >
> > The attached patch makes it so that we check the actual cpu type of the
> > host and then provide the same cpu type for the virtual machine.
>
> Windows crashes immediately with this patch (STOP: 0x7E (0xc0000005 
> 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode 
> BSODs), so either it's doing too much or not enough.

32 or 64 bit and what are you running for the host?  There's definitely
more that _could_ be mirrored.  

> Note that we support migration from Intel to AMD and vice versa, so it 
> would be good to supply a command line parameter to set the cpuid (to a 
> least common denominator CPU).

The problem is that with current CPUs, I don't know that there really is
a least common denominator anymore.  Both Intel and AMD have their own
implementation of a number of things which aren't "core" bits --
performance counters, things to handle microcode updates, etc.  :-/

Are there any docs for the current state of migration?  Depending on how
it's done, this may not at least make things any "worse" for the
migration case since we're only changing things at CPU startup, not
runtime calls to cpuid.  

Jeremy


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Avi Kivity]

Jeremy Katz wrote:
> On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote:
>   
>> Jeremy Katz wrote:
>>     
>>> Currently, kvm ends up just using the standard qemu cpu initialization.
>>> This means that all x86_64 virtual machines appear to have an
>>> AuthenticAMD (AMD64) processor.  This ends up causing a problem when
>>> booting some x86_64 Linux kernels as they attempt to do AMD64 specific
>>> initialization for things like performance counters.  Since those MSRs
>>> aren't supported on the Intel host, the virtual machine is halted.
>>>
>>> The attached patch makes it so that we check the actual cpu type of the
>>> host and then provide the same cpu type for the virtual machine.
>>>       
>> Windows crashes immediately with this patch (STOP: 0x7E (0xc0000005 
>> 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode 
>> BSODs), so either it's doing too much or not enough.
>>     
>
> 32 or 64 bit and what are you running for the host?  There's definitely
> more that _could_ be mirrored.  
>
>   

Host 64-bit Intel Pentium D; guest is 32-bit Windows XP Pro (64-bit 
Windows depends on the next qemu merge).

>> Note that we support migration from Intel to AMD and vice versa, so it 
>> would be good to supply a command line parameter to set the cpuid (to a 
>> least common denominator CPU).
>>     
>
> The problem is that with current CPUs, I don't know that there really is
> a least common denominator anymore.  Both Intel and AMD have their own
> implementation of a number of things which aren't "core" bits --
> performance counters, things to handle microcode updates, etc.  :-/
>
>   

One way around is to report a non-AMD, non-Intel processor ('FakeKVM' 
signature?)

But usually guests test for the feature using cpuid, so we just have to 
turn off a lot of bits there.

Note that qemu manages to run most hosts without emulating all those 
weird features, so it shouldn't be too hard.

> Are there any docs for the current state of migration?  Depending on how
> it's done,

Migration just moves the cpu state, the hardware state, and memory to 
another host.  Live migration does this in parallel with execution.

What do you mean by "current state of migration"?  How to run it for 
testing?

>  this may not at least make things any "worse" for the
> migration case since we're only changing things at CPU startup, not
> runtime calls to cpuid.  
>   

If you tell the host, for instance, that you support the AMD performance 
counters and then you migrate to Intel, things will break.  Best to tell 
the guest that you don't support performance counters at all (this is 
necessary from an isolation point of view as well).

Having said all that, I think the problem with your patch is just some 
minor internal inconsistency that causes Windows to barf.  Decoding the 
oops from the microsoft docs will probably shed some light on the matter.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Jeremy Katz]

On Thu, 2006-12-21 at 16:26 +0200, Avi Kivity wrote:
> Jeremy Katz wrote:
> > On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote:
> >> Jeremy Katz wrote:
> >>> Currently, kvm ends up just using the standard qemu cpu initialization.
> >>> This means that all x86_64 virtual machines appear to have an
> >>> AuthenticAMD (AMD64) processor.  This ends up causing a problem when
> >>> booting some x86_64 Linux kernels as they attempt to do AMD64 specific
> >>> initialization for things like performance counters.  Since those MSRs
> >>> aren't supported on the Intel host, the virtual machine is halted.
> >>>
> >>> The attached patch makes it so that we check the actual cpu type of the
> >>> host and then provide the same cpu type for the virtual machine.
> >>>       
> >> Windows crashes immediately with this patch (STOP: 0x7E (0xc0000005 
> >> 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode 
> >> BSODs), so either it's doing too much or not enough.
> >>     
> > 32 or 64 bit and what are you running for the host?  There's definitely
> > more that _could_ be mirrored.  
> >   
> 
> Host 64-bit Intel Pentium D; guest is 32-bit Windows XP Pro (64-bit 
> Windows depends on the next qemu merge).
>
> >> Note that we support migration from Intel to AMD and vice versa, so it 
> >> would be good to supply a command line parameter to set the cpuid (to a 
> >> least common denominator CPU).
> >
> > The problem is that with current CPUs, I don't know that there really is
> > a least common denominator anymore.  Both Intel and AMD have their own
> > implementation of a number of things which aren't "core" bits --
> > performance counters, things to handle microcode updates, etc.  :-/
> >   
> 
> One way around is to report a non-AMD, non-Intel processor ('FakeKVM' 
> signature?)

I'm not sure how different OS's will actually respond to that, either...
I have a sinking suspicion that it would definitely throw some for a
loop based on prior experiences with a new processor rollout :/

> But usually guests test for the feature using cpuid, so we just have to 
> turn off a lot of bits there.

There are a lot of things which aren't exposed as explicit features via
cpuid that an OS can and will care about.  Using cpuid to mask sse3 or
the like should be fine, but really doesn't take care of the breadth of
what's needed.

> Note that qemu manages to run most hosts without emulating all those 
> weird features, so it shouldn't be too hard.

For i386 qemu, it emulates a processor before a lot of the
vendor-specific features were really available (it looks like it
pretends to be a PentiumII).  x86_64 is much more of a state where there
are differences between the Intel and AMD chips and the "right" thing is
switched at runtime.

> > Are there any docs for the current state of migration?  Depending on how
> > it's done,
> 
> Migration just moves the cpu state, the hardware state, and memory to 
> another host.  Live migration does this in parallel with execution.
> 
> What do you mean by "current state of migration"?  How to run it for 
> testing?

Yep

> >  this may not at least make things any "worse" for the
> > migration case since we're only changing things at CPU startup, not
> > runtime calls to cpuid.  
> >   
> 
> If you tell the host, for instance, that you support the AMD performance 
> counters and then you migrate to Intel, things will break.  Best to tell 
> the guest that you don't support performance counters at all (this is 
> necessary from an isolation point of view as well).

The only thing that keys supporting the specific processor
features/msrs, though, is the vendor and model.  eg, see
arch/x86_64/kernel/nmi.c:setup_apic_nmi_watchdog().  It's not only
things that are expressed specifically from the cpuid (eg, mmx or sse)

> Having said all that, I think the problem with your patch is just some 
> minor internal inconsistency that causes Windows to barf.  Decoding the 
> oops from the microsoft docs will probably shed some light on the matter.

Indeed -- I'll try to find a Windows CD so that I can take a look this
afternoon.

Jeremy


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Avi Kivity]

Jeremy Katz wrote:
>> What do you mean by "current state of migration"?  How to run it for 
>> testing?
>>     
>
> Yep
>   

I've asked Uri to add a section to the web site.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Match virtual machine processor vendor to that of the host

[Avi Kivity]

Avi Kivity wrote:
> Jeremy Katz wrote:
>>> What do you mean by "current state of migration"?  How to run it for 
>>> testing?
>>>     
>>
>> Yep
>>   
>
> I've asked Uri to add a section to the web site.
>

This is now http://kvm.sourceforge.net/migration.html.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV