qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1297651] [NEW] KVM create a win7 guest with Qemu,


From: Gonglei (Arei)
Subject: Re: [Qemu-devel] [Bug 1297651] [NEW] KVM create a win7 guest with Qemu, it boots up fail
Date: Wed, 26 Mar 2014 07:10:16 +0000

Hi,

I also encounter the same problem. When I use the Qemu mainline and with 
-machine pc-i440fx-2.0, the win7 guest will show blue screen, and give me
"The BIOS in this system is not fully ACPI compliant. Please contact your system
 Vendor for an updated BIOS.
Technical information: 
*** STOP: 0x000000A5 (...)
"

But when I change the machine property to pc-i440fx-1.5, the guest boots up 
fine.

Best regards,
-Gonglei

> Title:
>   KVM create a win7 guest with Qemu, it boots up fail
> 
> Status in QEMU:
>   New
> 
> Bug description:
>   Environment:
>   ------------
>   Host OS (ia32/ia32e/IA64):ia32e
>   Guest OS (ia32/ia32e/IA64):ia32e
>   Guest OS Type (Linux/Windows):Windows
>   kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a01111d5dc0
>   qemu-kvm Commit:839a5547574e57cce62f49bfc50fe1f04b00589a
>   Host Kernel Version:3.14.0-rc3
>   Hardware:Romley_EP, Ivytown_EP, HSW_EP
> 
> 
>   Bug detailed description:
>   --------------------------
>   when create a win7 guest, the guest boot up fail.
> 
>   note:
>   1. when create win2000, winxp, win2k3, win2k8, guest, the guest boot up
> fail.
>   2. when create win8, win8.1, win2012 guest, the guest boot up fine.
> 
> 
>   Reproduce steps:
>   ----------------
>   1.create guest
>   qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none -hda
> /root/win7.qcow
> 
> 
>   Current result:
>   ----------------
>   win7 guest boot up fail
> 
>   Expected result:
>   ----------------
>   win7 guest boot up fine
> 
>   Basic root-causing log:
>   ----------------------
> 
>   This should be a qemu bug
>   kvm      + qemu     =  result
>   94b3ffcd + 839a5547 = bad
>   94b3ffcd + 3a87f8b6 = good
> 
>   the first bad commit is:
>   commit 9bcc80cd71892df42605e0c097d85c0237ff45d1
>   Author: Laszlo Ersek <address@hidden>
>   Date:   Mon Mar 17 17:05:16 2014 +0100
> 
>       i386/acpi-build: allow more than 255 elements in CPON
> 
>       The build_ssdt() function builds a number of AML objects that are
> related
>       to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
>       (APIC IDs are in fact discontiguous, but this is the traditional
>       interface: build a contiguous sequence from zero up that covers all
>       possible APIC IDs.) These objects are:
> 
>       - a Processor() object for each VCPU,
>       - a NTFY method, with one branch for each VCPU,
>       - a CPON package with one element (hotplug status byte) for each
> VCPU.
> 
>       The build_ssdt() function currently limits the *count* of processor
>       objects, and NTFY branches, and CPON elements, in 0xFF (see the
> assignment
>       to "acpi_cpus"). This allows for an inclusive APIC ID range of [0..254].
>       This is incorrect, because the highest APIC ID that we otherwise allow a
>       VCPU to take is 255.
> 
>       In order to extend the maximum count to 256, and the traversed APIC
> ID
>       range correspondingly to [0..255]:
>       - the Processor() objects need no change,
>       - the NTFY method also needs no change,
>       - the CPON package must be updated, because it is defined with a
>         DefPackage, and the number of elements in such a package can be at
> most
>         255. We pick a DefVarPackage instead.
> 
>       We replace the Op byte, and the encoding of the number of elements.
>       Compare:
> 
>       DefPackage     := PackageOp    PkgLength NumElements
> PackageElementList
>       DefVarPackage  := VarPackageOp PkgLength VarNumElements
> PackageElementList
> 
>       PackageOp      := 0x12
>       VarPackageOp   := 0x13
> 
>       NumElements    := ByteData
>       VarNumElements := TermArg => Integer
> 
>       The build_append_int() function implements precisely the following
> TermArg
>       encodings (a subset of what the ACPI spec describes):
> 
>         TermArg             := DataObject
>         DataObject          := ComputationalData
>         ComputationalData   := ConstObj | ByteConst | WordConst |
> DWordConst
>         directly encoded in the function, with build_append_byte():
>           ConstObj          := ZeroOp | OneOp
>             ZeroOp          := 0x00
>             OneOp           := 0x01
> 
>         call to build_append_value(..., 1):
>           ByteConst         := BytePrefix ByteData
>             BytePrefix      := 0x0A
>             ByteData        := 0x00 - 0xFF
> 
>         call to build_append_value(..., 2):
>           WordConst         := WordPrefix WordData
>             WordPrefix      := 0x0B
>             WordData        := ByteData[0:7] ByteData[8:15]
> 
>         call to build_append_value(..., 4):
>           DWordConst        := DWordPrefix DWordData
>             DWordPrefix     := 0x0C
>             DWordData       := WordData[0:15] WordData[16:31]
> 
>       Signed-off-by: Laszlo Ersek <address@hidden>
>       Reviewed-by: Michael S. Tsirkin <address@hidden>
>       Signed-off-by: Michael S. Tsirkin <address@hidden>
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions


reply via email to

[Prev in Thread] Current Thread [Next in Thread]