From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Booting/installing WindowsNT Date: Wed, 05 May 2010 14:35:40 +0300 Message-ID: <4BE1580C.7030305@redhat.com> References: <4BDB44C2.7090204@msgid.tls.msk.ru> <4BDB4E58.50805@msgid.tls.msk.ru> <4BDD4E32.2080503@redhat.com> <4BDDA455.8090001@msgid.tls.msk.ru> <4BDE882F.5000009@amd.com> <4BDE8DF4.8070604@redhat.com> <4BDE9757.8090809@amd.com> <4BDF01CA.80505@msgid.tls.msk.ru> <4BDFE3A7.2050706@redhat.com> <4BE00E2A.2010901@amd.com> <4BE015BF.2010401@msgid.tls.msk.ru> <4BE03CD7.8090105@amd.com> <4BE049F5.4000500@redhat.com> <4BE12D1E.5000602@amd.com> <4BE131AA.8040506@msgid.tls.msk.ru> <4BE14611.4080307@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , KVM list To: Andre Przywara Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21746 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755463Ab0EELfp (ORCPT ); Wed, 5 May 2010 07:35:45 -0400 In-Reply-To: <4BE14611.4080307@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/05/2010 01:18 PM, Andre Przywara wrote: > Michael Tokarev wrote: >> 05.05.2010 12:32, Andre Przywara wrote: >>> Avi Kivity wrote: >>>> On 05/04/2010 06:27 PM, Andre Przywara wrote: >>>>> >>>>>> 3. In all other cases so far it BSoDs with STOP 0x3E error >>>>>> right before displaying that kernel message. >>>>> MSDN talks about a mulitprocessor configuration error: >>>>> http://msdn.microsoft.com/en-us/library/ms819006.aspx >>>>> I suspected the offline CPUs in the mptable that confuse NT. But -smp >>>>> 1,maxcpus=1 does not make a difference. I will try to dig deeper in >>>>> this area. >>> OK, I tackled this down. It is the max CPUID level that differs. >>> In the AMD CPUID guide leafs 0000_0002 till 0000_0004 are reserved, the >>> CPU that Michael and I used (K8RevF) actually have a max leaf of 1 >>> here. >>> Default qemu64 has a max leaf of 4. >>> So by saying -cpu qemu64,level=1 (or 2 or 3) it works for me. >>> Modern OS only read leaf 4 on Intel systems, it seems that NT4 is >>> missing this. >> >> Confirmed, with -cpu qemu64,level=[123] it works for me as well. > The strange thing is that NT4 never reads leaf 4: > kvm-2341 [003] 228.527874: kvm_cpuid: func 40000000 rax 0 rbx > 4b4d564b rcx 564b4d56 rdx 4d > kvm-2341 [003] 228.530033: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2341 [003] 228.530081: kvm_cpuid: func 80000000 rax 8000000a > rbx 68747541 rcx 444d4163 rdx 69746e65 > kvm-2341 [003] 228.530084: kvm_cpuid: func 80000008 rax 3028 rbx 0 > rcx 0 rdx 0 > kvm-2341 [003] 228.530147: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2341 [002] 228.538254: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2341 [002] 228.539902: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2341 [002] 236.273370: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2341 [002] 236.273381: kvm_cpuid: func 0 rax 4 rbx 68747541 rcx > 444d4163 rdx 69746e65 So maybe it's just a simple guest bug that was never encountered in real life because no processors had that leaf. > > With level=4 it BSODs afterwards, with level=1 it beyond that: > kvm-2472 [002] 871.379192: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > kvm-2472 [002] 871.379235: kvm_cpuid: func 0 rax 1 rbx 68747541 rcx > 444d4163 rdx 69746e65 > kvm-2472 [002] 871.379238: kvm_cpuid: func 1 rax 623 rbx 800 rcx > 80002001 rdx 78bfbfd > .... > > Interestingly it also accesses leaf 8000_0008, I thought that that > leaf wasn't around in 1996. It's the bios: src/mtrr.c: cpuid(0x80000008u, &eax, &ebx, &ecx, &edx); -- error compiling committee.c: too many arguments to function