[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1297651] [NEW] KVM create a win7 guest with Qemu, it b
|
From: |
Robert Hu |
|
Subject: |
[Qemu-devel] [Bug 1297651] [NEW] KVM create a win7 guest with Qemu, it boots up fail |
|
Date: |
Wed, 26 Mar 2014 06:45:10 -0000 |
Public bug reported:
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>
** Affects: qemu
Importance: Undecided
Status: New
--
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