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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
