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

[Michael S. Tsirkin]

On Wed, Mar 26, 2014 at 07:16:42AM +0000, Gonglei (Arei) wrote:
> 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

Thanks!
I just sent a patch to fix this, could you take a look please?


> > 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
>