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

2014-04-03 Thread Serge Hallyn
** Changed in: qemu
   Status: New => Fix Released

-- 
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:
  Fix Released

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Windows
  kvm.git Commit:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  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 
  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 := PackageOpPkgLength NumElementsPackageElementList
  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 
  Reviewed-by: Michael S. Tsirkin 
  Signed-off-by: Michael S. Tsirkin 

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions



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

2014-03-27 Thread Robert Hu
[root@localhost qemu]# git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
[root@localhost qemu]# git log db237e33
commit db237e33c08a279f0179f8f5128a6d10d9adc38a
Merge: 61898bc ad1c7e0
Author: Peter Maydell 
Date:   Wed Mar 26 17:10:15 2014 +

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 

-- 
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:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  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 
  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 := PackageOpPkgLength NumElementsPackageElementList
  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 
  Reviewed-by: Michael S. Tsirkin 
  Signed-off-by: Michael S. Tsirkin 

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions



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

2014-03-27 Thread Serge Hallyn
Quoting Robert Hu (robert...@intel.com):
> on latest commit (db237e33), this bug doesn't exit.

Sorry, I don't see this commit in qemu.git?

-- 
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:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  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 
  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 := PackageOpPkgLength NumElementsPackageElementList
  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 
  Reviewed-by: Michael S. Tsirkin 
  Signed-off-by: Michael S. Tsirkin 

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions



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

2014-03-26 Thread Robert Hu
on latest commit (db237e33), this bug doesn't exit.

-- 
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:94b3ffcd41a90d2cb0b32ca23aa58a0d5dc0
  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 
  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 := PackageOpPkgLength NumElementsPackageElementList
  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 
  Reviewed-by: Michael S. Tsirkin 
  Signed-off-by: Michael S. Tsirkin 

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297651/+subscriptions