qemu-devel
[Top][All Lists]
Advanced

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

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


From: Robert Hu
Subject: [Qemu-devel] [Bug 1297651] Re: KVM create a win7 guest with Qemu, it boots up fail
Date: Fri, 28 Mar 2014 02:22:16 -0000

address@hidden qemu]# git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
address@hidden qemu]# git log db237e33
commit db237e33c08a279f0179f8f5128a6d10d9adc38a
Merge: 61898bc ad1c7e0
Author: Peter Maydell <address@hidden>
Date:   Wed Mar 26 17:10:15 2014 +0000

    Merge remote-tracking branch 'remotes/riku/for-2.0' into staging

    * remotes/riku/for-2.0:
      linux-user: Correct DLINFO_ITEMS

    Signed-off-by: Peter Maydell <address@hidden>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297651

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]