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

[Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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