* [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
@ 2010-01-21 11:48 Liu, Jinsong
2010-01-21 12:44 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-21 11:48 UTC (permalink / raw)
To: kvm@vger.kernel.org; +Cc: Avi Kivity
>From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 22 Jan 2010 03:18:46 +0800
Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
1. setup madt bios_info structure, so that static dsdt get
run-time madt info like checksum address, lapic address,
max cpu numbers, with least hardcode magic number (realmode
address of bios_info).
2. setup vcpu add/remove dsdt infrastructure, including processor
related acpi objects and control methods. vcpu add/remove will
trigger SCI and then control method _L02. By matching madt, vcpu
number and add/remove action were found, then by notify control
method, it will notify OS acpi driver.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
src/acpi-dsdt.dsl | 131 ++++++++++++++++-
src/acpi-dsdt.hex | 441 ++++++++++++++++++++++++++++++++++++++++++++++++++---
src/acpi.c | 7 +
src/biosvar.h | 14 ++
src/post.c | 13 ++
5 files changed, 582 insertions(+), 24 deletions(-)
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index cc31112..ed78489 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -700,8 +700,11 @@ DefinitionBlock (
Return (0x01)
}
+ /*
+ * _L02 method for CPU notification
+ */
Method(_L02) {
- Return(0x01)
+ Return(\_PR.PRSC())
}
Method(_L03) {
Return(0x01)
@@ -744,4 +747,130 @@ DefinitionBlock (
}
}
+
+ Scope (\_PR)
+ {
+ /* BIOS_INFO_PHYSICAL_ADDRESS == 0xEA000 */
+ OperationRegion(BIOS, SystemMemory, 0xEA000, 16)
+ Field(BIOS, DwordAcc, NoLock, Preserve)
+ {
+ MSUA, 32, /* MADT checksum address */
+ MAPA, 32, /* MADT LAPIC0 address */
+ PBYT, 32, /* bytes of max vcpus bitmap */
+ PBIT, 32 /* bits of last byte of max vcpus bitmap */
+ }
+
+ OperationRegion(MSUM, SystemMemory, MSUA, 1)
+ Field(MSUM, ByteAcc, NoLock, Preserve)
+ {
+ MSU, 8 /* MADT checksum */
+ }
+
+ #define gen_processor(nr, name) \
+ Processor (C##name, nr, 0x0000b010, 0x06) { \
+ Name (_HID, "ACPI0007") \
+ OperationRegion(MATR, SystemMemory, Add(MAPA, Multiply(nr,8)), 8) \
+ Field (MATR, ByteAcc, NoLock, Preserve) \
+ { \
+ MAT, 64 \
+ } \
+ Field (MATR, ByteAcc, NoLock, Preserve) \
+ { \
+ Offset(4), \
+ FLG, 1 \
+ } \
+ Method(_MAT, 0) { \
+ Return(ToBuffer(MAT)) \
+ } \
+ Method (_STA) { \
+ If (FLG) { Return(0xF) } Else { Return(0x9) } \
+ } \
+ Method (_EJ0, 1, NotSerialized) { \
+ Sleep (0xC8) \
+ } \
+ } \
+
+ gen_processor(0, 0)
+ gen_processor(1, 1)
+ gen_processor(2, 2)
+ gen_processor(3, 3)
+ gen_processor(4, 4)
+ gen_processor(5, 5)
+ gen_processor(6, 6)
+ gen_processor(7, 7)
+ gen_processor(8, 8)
+ gen_processor(9, 9)
+ gen_processor(10, A)
+ gen_processor(11, B)
+ gen_processor(12, C)
+ gen_processor(13, D)
+ gen_processor(14, E)
+
+
+ Method (NTFY, 2) {
+ #define gen_ntfy(nr) \
+ If (LEqual(Arg0, 0x##nr)) { \
+ If (LNotEqual(Arg1, \_PR.C##nr.FLG)) { \
+ Store (Arg1, \_PR.C##nr.FLG) \
+ If (LEqual(Arg1, 1)) { \
+ Notify(C##nr, 1) \
+ Subtract(\_PR.MSU, 1, \_PR.MSU) \
+ } Else { \
+ Notify(C##nr, 3) \
+ Add(\_PR.MSU, 1, \_PR.MSU) \
+ } \
+ } \
+ }
+
+ gen_ntfy(0)
+ gen_ntfy(1)
+ gen_ntfy(2)
+ gen_ntfy(3)
+ gen_ntfy(4)
+ gen_ntfy(5)
+ gen_ntfy(6)
+ gen_ntfy(7)
+ gen_ntfy(8)
+ gen_ntfy(9)
+ gen_ntfy(A)
+ gen_ntfy(B)
+ gen_ntfy(C)
+ gen_ntfy(D)
+ gen_ntfy(E)
+
+ Return(One)
+ }
+
+
+ OperationRegion(PRST, SystemIO, 0xaf00, 32)
+ Field (PRST, ByteAcc, NoLock, Preserve)
+ {
+ PRS, 256
+ }
+
+ Method(PRSC, 0) {
+ Store(PRS, Local3)
+ Store(Zero, Local0)
+ While(LLess(Local0, \_PR.PBYT)) {
+ Store(Zero, Local1)
+ Store(DerefOf(Index(Local3, Local0)), Local2)
+ While(LLess(Local1, 8)) {
+ NTFY(Add(Multiply(Local0, 8), Local1), And(Local2, 1))
+ ShiftRight(Local2, 1, Local2)
+ Increment(Local1)
+ }
+ Increment(Local0)
+ }
+
+ Store(Zero, Local1)
+ Store(DerefOf(Index(Local3, Local0)), Local2)
+ While(LLess(Local1, \_PR.PBIT)) {
+ NTFY(Add(Multiply(Local0, 8), Local1), And(Local2, 1))
+ ShiftRight(Local2, 1, Local2)
+ Increment(Local1)
+ }
+
+ Return(One)
+ }
+ }
}
diff --git a/src/acpi-dsdt.hex b/src/acpi-dsdt.hex
index 465e93e..85d6d69 100644
--- a/src/acpi-dsdt.hex
+++ b/src/acpi-dsdt.hex
@@ -1,22 +1,22 @@
/*
*
* Intel ACPI Component Architecture
- * ASL Optimizing Compiler version 20090123 [Feb 25 2009]
- * Copyright (C) 2000 - 2009 Intel Corporation
+ * ASL Optimizing Compiler version 20061109 [Jul 16 2007]
+ * Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
- * Compilation of "out/acpi-dsdt.dsl.i" - Wed Dec 30 12:30:21 2009
+ * Compilation of "out/acpi-dsdt.dsl.i" - Fri Jan 22 02:12:21 2010
*
* C source code output
*
*/
unsigned char AmlCode[] =
{
- 0x44,0x53,0x44,0x54,0x22,0x1E,0x00,0x00, /* 00000000 "DSDT"..." */
- 0x01,0x71,0x42,0x58,0x50,0x43,0x00,0x00, /* 00000008 ".qBXPC.." */
+ 0x44,0x53,0x44,0x54,0x7D,0x2A,0x00,0x00, /* 00000000 "DSDT}*.." */
+ 0x01,0x68,0x42,0x58,0x50,0x43,0x00,0x00, /* 00000008 ".hBXPC.." */
0x42,0x58,0x44,0x53,0x44,0x54,0x00,0x00, /* 00000010 "BXDSDT.." */
0x01,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */
- 0x23,0x01,0x09,0x20,0x10,0x1C,0x5C,0x00, /* 00000020 "#.. ..\." */
+ 0x09,0x11,0x06,0x20,0x10,0x1C,0x5C,0x00, /* 00000020 "... ..\." */
0x5B,0x80,0x44,0x42,0x47,0x5F,0x01,0x0B, /* 00000028 "[.DBG_.." */
0x44,0xB0,0x0A,0x04,0x5B,0x81,0x0B,0x44, /* 00000030 "D...[..D" */
0x42,0x47,0x5F,0x03,0x44,0x42,0x47,0x4C, /* 00000038 "BG_.DBGL" */
@@ -643,7 +643,7 @@ unsigned char AmlCode[] =
0x08,0x5F,0x53,0x34,0x5F,0x12,0x06,0x04, /* 000013A0 "._S4_..." */
0x00,0x00,0x00,0x00,0x08,0x5F,0x53,0x35, /* 000013A8 "....._S5" */
0x5F,0x12,0x06,0x04,0x00,0x00,0x00,0x00, /* 000013B0 "_......." */
- 0x10,0x49,0xA6,0x5F,0x47,0x50,0x45,0x08, /* 000013B8 ".I._GPE." */
+ 0x10,0x42,0xA7,0x5F,0x47,0x50,0x45,0x08, /* 000013B8 ".B._GPE." */
0x5F,0x48,0x49,0x44,0x0D,0x41,0x43,0x50, /* 000013C0 "_HID.ACP" */
0x49,0x30,0x30,0x30,0x36,0x00,0x14,0x08, /* 000013C8 "I0006..." */
0x5F,0x4C,0x30,0x30,0x00,0xA4,0x01,0x14, /* 000013D0 "_L00...." */
@@ -960,21 +960,416 @@ unsigned char AmlCode[] =
0x49,0x44,0x0C,0x00,0x00,0x00,0x80,0x00, /* 00001D88 "ID......" */
0x86,0x5C,0x2F,0x03,0x5F,0x53,0x42,0x5F, /* 00001D90 ".\/._SB_" */
0x50,0x43,0x49,0x30,0x53,0x33,0x31,0x5F, /* 00001D98 "PCI0S31_" */
- 0x0A,0x03,0xA4,0x01,0x14,0x08,0x5F,0x4C, /* 00001DA0 "......_L" */
- 0x30,0x32,0x00,0xA4,0x01,0x14,0x08,0x5F, /* 00001DA8 "02....._" */
- 0x4C,0x30,0x33,0x00,0xA4,0x01,0x14,0x08, /* 00001DB0 "L03....." */
- 0x5F,0x4C,0x30,0x34,0x00,0xA4,0x01,0x14, /* 00001DB8 "_L04...." */
- 0x08,0x5F,0x4C,0x30,0x35,0x00,0xA4,0x01, /* 00001DC0 "._L05..." */
- 0x14,0x08,0x5F,0x4C,0x30,0x36,0x00,0xA4, /* 00001DC8 ".._L06.." */
- 0x01,0x14,0x08,0x5F,0x4C,0x30,0x37,0x00, /* 00001DD0 "..._L07." */
- 0xA4,0x01,0x14,0x08,0x5F,0x4C,0x30,0x38, /* 00001DD8 "...._L08" */
+ 0x0A,0x03,0xA4,0x01,0x14,0x11,0x5F,0x4C, /* 00001DA0 "......_L" */
+ 0x30,0x32,0x00,0xA4,0x5C,0x2E,0x5F,0x50, /* 00001DA8 "02..\._P" */
+ 0x52,0x5F,0x50,0x52,0x53,0x43,0x14,0x08, /* 00001DB0 "R_PRSC.." */
+ 0x5F,0x4C,0x30,0x33,0x00,0xA4,0x01,0x14, /* 00001DB8 "_L03...." */
+ 0x08,0x5F,0x4C,0x30,0x34,0x00,0xA4,0x01, /* 00001DC0 "._L04..." */
+ 0x14,0x08,0x5F,0x4C,0x30,0x35,0x00,0xA4, /* 00001DC8 ".._L05.." */
+ 0x01,0x14,0x08,0x5F,0x4C,0x30,0x36,0x00, /* 00001DD0 "..._L06." */
+ 0xA4,0x01,0x14,0x08,0x5F,0x4C,0x30,0x37, /* 00001DD8 "...._L07" */
0x00,0xA4,0x01,0x14,0x08,0x5F,0x4C,0x30, /* 00001DE0 "....._L0" */
- 0x39,0x00,0xA4,0x01,0x14,0x08,0x5F,0x4C, /* 00001DE8 "9....._L" */
- 0x30,0x41,0x00,0xA4,0x01,0x14,0x08,0x5F, /* 00001DF0 "0A....._" */
- 0x4C,0x30,0x42,0x00,0xA4,0x01,0x14,0x08, /* 00001DF8 "L0B....." */
- 0x5F,0x4C,0x30,0x43,0x00,0xA4,0x01,0x14, /* 00001E00 "_L0C...." */
- 0x08,0x5F,0x4C,0x30,0x44,0x00,0xA4,0x01, /* 00001E08 "._L0D..." */
- 0x14,0x08,0x5F,0x4C,0x30,0x45,0x00,0xA4, /* 00001E10 ".._L0E.." */
- 0x01,0x14,0x08,0x5F,0x4C,0x30,0x46,0x00, /* 00001E18 "..._L0F." */
- 0xA4,0x01,
+ 0x38,0x00,0xA4,0x01,0x14,0x08,0x5F,0x4C, /* 00001DE8 "8....._L" */
+ 0x30,0x39,0x00,0xA4,0x01,0x14,0x08,0x5F, /* 00001DF0 "09....._" */
+ 0x4C,0x30,0x41,0x00,0xA4,0x01,0x14,0x08, /* 00001DF8 "L0A....." */
+ 0x5F,0x4C,0x30,0x42,0x00,0xA4,0x01,0x14, /* 00001E00 "_L0B...." */
+ 0x08,0x5F,0x4C,0x30,0x43,0x00,0xA4,0x01, /* 00001E08 "._L0C..." */
+ 0x14,0x08,0x5F,0x4C,0x30,0x44,0x00,0xA4, /* 00001E10 ".._L0D.." */
+ 0x01,0x14,0x08,0x5F,0x4C,0x30,0x45,0x00, /* 00001E18 "..._L0E." */
+ 0xA4,0x01,0x14,0x08,0x5F,0x4C,0x30,0x46, /* 00001E20 "...._L0F" */
+ 0x00,0xA4,0x01,0x10,0x41,0xC5,0x5F,0x50, /* 00001E28 "....A._P" */
+ 0x52,0x5F,0x5B,0x80,0x42,0x49,0x4F,0x53, /* 00001E30 "R_[.BIOS" */
+ 0x00,0x0C,0x00,0xA0,0x0E,0x00,0x0A,0x10, /* 00001E38 "........" */
+ 0x5B,0x81,0x1A,0x42,0x49,0x4F,0x53,0x03, /* 00001E40 "[..BIOS." */
+ 0x4D,0x53,0x55,0x41,0x20,0x4D,0x41,0x50, /* 00001E48 "MSUA MAP" */
+ 0x41,0x20,0x50,0x42,0x59,0x54,0x20,0x50, /* 00001E50 "A PBYT P" */
+ 0x42,0x49,0x54,0x20,0x5B,0x80,0x4D,0x53, /* 00001E58 "BIT [.MS" */
+ 0x55,0x4D,0x00,0x4D,0x53,0x55,0x41,0x01, /* 00001E60 "UM.MSUA." */
+ 0x5B,0x81,0x0B,0x4D,0x53,0x55,0x4D,0x01, /* 00001E68 "[..MSUM." */
+ 0x4D,0x53,0x55,0x5F,0x08,0x5B,0x83,0x46, /* 00001E70 "MSU_.[.F" */
+ 0x07,0x43,0x30,0x5F,0x5F,0x00,0x10,0xB0, /* 00001E78 ".C0__..." */
+ 0x00,0x00,0x06,0x08,0x5F,0x48,0x49,0x44, /* 00001E80 "...._HID" */
+ 0x0D,0x41,0x43,0x50,0x49,0x30,0x30,0x30, /* 00001E88 ".ACPI000" */
+ 0x37,0x00,0x5B,0x80,0x4D,0x41,0x54,0x52, /* 00001E90 "7.[.MATR" */
+ 0x00,0x72,0x4D,0x41,0x50,0x41,0x00,0x00, /* 00001E98 ".rMAPA.." */
+ 0x0A,0x08,0x5B,0x81,0x0C,0x4D,0x41,0x54, /* 00001EA0 "..[..MAT" */
+ 0x52,0x01,0x4D,0x41,0x54,0x5F,0x40,0x04, /* 00001EA8 "R.MAT_@." */
+ 0x5B,0x81,0x0D,0x4D,0x41,0x54,0x52,0x01, /* 00001EB0 "[..MATR." */
+ 0x00,0x20,0x46,0x4C,0x47,0x5F,0x01,0x14, /* 00001EB8 ". FLG_.." */
+ 0x0D,0x5F,0x4D,0x41,0x54,0x00,0xA4,0x96, /* 00001EC0 "._MAT..." */
+ 0x4D,0x41,0x54,0x5F,0x00,0x14,0x14,0x5F, /* 00001EC8 "MAT_..._" */
+ 0x53,0x54,0x41,0x00,0xA0,0x08,0x46,0x4C, /* 00001ED0 "STA...FL" */
+ 0x47,0x5F,0xA4,0x0A,0x0F,0xA1,0x04,0xA4, /* 00001ED8 "G_......" */
+ 0x0A,0x09,0x14,0x0A,0x5F,0x45,0x4A,0x30, /* 00001EE0 "...._EJ0" */
+ 0x01,0x5B,0x22,0x0A,0xC8,0x5B,0x83,0x47, /* 00001EE8 ".["..[.G" */
+ 0x07,0x43,0x31,0x5F,0x5F,0x01,0x10,0xB0, /* 00001EF0 ".C1__..." */
+ 0x00,0x00,0x06,0x08,0x5F,0x48,0x49,0x44, /* 00001EF8 "...._HID" */
+ 0x0D,0x41,0x43,0x50,0x49,0x30,0x30,0x30, /* 00001F00 ".ACPI000" */
+ 0x37,0x00,0x5B,0x80,0x4D,0x41,0x54,0x52, /* 00001F08 "7.[.MATR" */
+ 0x00,0x72,0x4D,0x41,0x50,0x41,0x0A,0x08, /* 00001F10 ".rMAPA.." */
+ 0x00,0x0A,0x08,0x5B,0x81,0x0C,0x4D,0x41, /* 00001F18 "...[..MA" */
+ 0x54,0x52,0x01,0x4D,0x41,0x54,0x5F,0x40, /* 00001F20 "TR.MAT_@" */
+ 0x04,0x5B,0x81,0x0D,0x4D,0x41,0x54,0x52, /* 00001F28 ".[..MATR" */
+ 0x01,0x00,0x20,0x46,0x4C,0x47,0x5F,0x01, /* 00001F30 ".. FLG_." */
+ 0x14,0x0D,0x5F,0x4D,0x41,0x54,0x00,0xA4, /* 00001F38 ".._MAT.." */
+ 0x96,0x4D,0x41,0x54,0x5F,0x00,0x14,0x14, /* 00001F40 ".MAT_..." */
+ 0x5F,0x53,0x54,0x41,0x00,0xA0,0x08,0x46, /* 00001F48 "_STA...F" */
+ 0x4C,0x47,0x5F,0xA4,0x0A,0x0F,0xA1,0x04, /* 00001F50 "LG_....." */
+ 0xA4,0x0A,0x09,0x14,0x0A,0x5F,0x45,0x4A, /* 00001F58 "....._EJ" */
+ 0x30,0x01,0x5B,0x22,0x0A,0xC8,0x5B,0x83, /* 00001F60 "0.["..[." */
+ 0x47,0x07,0x43,0x32,0x5F,0x5F,0x02,0x10, /* 00001F68 "G.C2__.." */
+ 0xB0,0x00,0x00,0x06,0x08,0x5F,0x48,0x49, /* 00001F70 "....._HI" */
+ 0x44,0x0D,0x41,0x43,0x50,0x49,0x30,0x30, /* 00001F78 "D.ACPI00" */
+ 0x30,0x37,0x00,0x5B,0x80,0x4D,0x41,0x54, /* 00001F80 "07.[.MAT" */
+ 0x52,0x00,0x72,0x4D,0x41,0x50,0x41,0x0A, /* 00001F88 "R.rMAPA." */
+ 0x10,0x00,0x0A,0x08,0x5B,0x81,0x0C,0x4D, /* 00001F90 "....[..M" */
+ 0x41,0x54,0x52,0x01,0x4D,0x41,0x54,0x5F, /* 00001F98 "ATR.MAT_" */
+ 0x40,0x04,0x5B,0x81,0x0D,0x4D,0x41,0x54, /* 00001FA0 "@.[..MAT" */
+ 0x52,0x01,0x00,0x20,0x46,0x4C,0x47,0x5F, /* 00001FA8 "R.. FLG_" */
+ 0x01,0x14,0x0D,0x5F,0x4D,0x41,0x54,0x00, /* 00001FB0 "..._MAT." */
+ 0xA4,0x96,0x4D,0x41,0x54,0x5F,0x00,0x14, /* 00001FB8 "..MAT_.." */
+ 0x14,0x5F,0x53,0x54,0x41,0x00,0xA0,0x08, /* 00001FC0 "._STA..." */
+ 0x46,0x4C,0x47,0x5F,0xA4,0x0A,0x0F,0xA1, /* 00001FC8 "FLG_...." */
+ 0x04,0xA4,0x0A,0x09,0x14,0x0A,0x5F,0x45, /* 00001FD0 "......_E" */
+ 0x4A,0x30,0x01,0x5B,0x22,0x0A,0xC8,0x5B, /* 00001FD8 "J0.["..[" */
+ 0x83,0x47,0x07,0x43,0x33,0x5F,0x5F,0x03, /* 00001FE0 ".G.C3__." */
+ 0x10,0xB0,0x00,0x00,0x06,0x08,0x5F,0x48, /* 00001FE8 "......_H" */
+ 0x49,0x44,0x0D,0x41,0x43,0x50,0x49,0x30, /* 00001FF0 "ID.ACPI0" */
+ 0x30,0x30,0x37,0x00,0x5B,0x80,0x4D,0x41, /* 00001FF8 "007.[.MA" */
+ 0x54,0x52,0x00,0x72,0x4D,0x41,0x50,0x41, /* 00002000 "TR.rMAPA" */
+ 0x0A,0x18,0x00,0x0A,0x08,0x5B,0x81,0x0C, /* 00002008 ".....[.." */
+ 0x4D,0x41,0x54,0x52,0x01,0x4D,0x41,0x54, /* 00002010 "MATR.MAT" */
+ 0x5F,0x40,0x04,0x5B,0x81,0x0D,0x4D,0x41, /* 00002018 "_@.[..MA" */
+ 0x54,0x52,0x01,0x00,0x20,0x46,0x4C,0x47, /* 00002020 "TR.. FLG" */
+ 0x5F,0x01,0x14,0x0D,0x5F,0x4D,0x41,0x54, /* 00002028 "_..._MAT" */
+ 0x00,0xA4,0x96,0x4D,0x41,0x54,0x5F,0x00, /* 00002030 "...MAT_." */
+ 0x14,0x14,0x5F,0x53,0x54,0x41,0x00,0xA0, /* 00002038 ".._STA.." */
+ 0x08,0x46,0x4C,0x47,0x5F,0xA4,0x0A,0x0F, /* 00002040 ".FLG_..." */
+ 0xA1,0x04,0xA4,0x0A,0x09,0x14,0x0A,0x5F, /* 00002048 "......._" */
+ 0x45,0x4A,0x30,0x01,0x5B,0x22,0x0A,0xC8, /* 00002050 "EJ0.[".." */
+ 0x5B,0x83,0x47,0x07,0x43,0x34,0x5F,0x5F, /* 00002058 "[.G.C4__" */
+ 0x04,0x10,0xB0,0x00,0x00,0x06,0x08,0x5F, /* 00002060 "......._" */
+ 0x48,0x49,0x44,0x0D,0x41,0x43,0x50,0x49, /* 00002068 "HID.ACPI" */
+ 0x30,0x30,0x30,0x37,0x00,0x5B,0x80,0x4D, /* 00002070 "0007.[.M" */
+ 0x41,0x54,0x52,0x00,0x72,0x4D,0x41,0x50, /* 00002078 "ATR.rMAP" */
+ 0x41,0x0A,0x20,0x00,0x0A,0x08,0x5B,0x81, /* 00002080 "A. ...[." */
+ 0x0C,0x4D,0x41,0x54,0x52,0x01,0x4D,0x41, /* 00002088 ".MATR.MA" */
+ 0x54,0x5F,0x40,0x04,0x5B,0x81,0x0D,0x4D, /* 00002090 "T_@.[..M" */
+ 0x41,0x54,0x52,0x01,0x00,0x20,0x46,0x4C, /* 00002098 "ATR.. FL" */
+ 0x47,0x5F,0x01,0x14,0x0D,0x5F,0x4D,0x41, /* 000020A0 "G_..._MA" */
+ 0x54,0x00,0xA4,0x96,0x4D,0x41,0x54,0x5F, /* 000020A8 "T...MAT_" */
+ 0x00,0x14,0x14,0x5F,0x53,0x54,0x41,0x00, /* 000020B0 "..._STA." */
+ 0xA0,0x08,0x46,0x4C,0x47,0x5F,0xA4,0x0A, /* 000020B8 "..FLG_.." */
+ 0x0F,0xA1,0x04,0xA4,0x0A,0x09,0x14,0x0A, /* 000020C0 "........" */
+ 0x5F,0x45,0x4A,0x30,0x01,0x5B,0x22,0x0A, /* 000020C8 "_EJ0.["." */
+ 0xC8,0x5B,0x83,0x47,0x07,0x43,0x35,0x5F, /* 000020D0 ".[.G.C5_" */
+ 0x5F,0x05,0x10,0xB0,0x00,0x00,0x06,0x08, /* 000020D8 "_......." */
+ 0x5F,0x48,0x49,0x44,0x0D,0x41,0x43,0x50, /* 000020E0 "_HID.ACP" */
+ 0x49,0x30,0x30,0x30,0x37,0x00,0x5B,0x80, /* 000020E8 "I0007.[." */
+ 0x4D,0x41,0x54,0x52,0x00,0x72,0x4D,0x41, /* 000020F0 "MATR.rMA" */
+ 0x50,0x41,0x0A,0x28,0x00,0x0A,0x08,0x5B, /* 000020F8 "PA.(...[" */
+ 0x81,0x0C,0x4D,0x41,0x54,0x52,0x01,0x4D, /* 00002100 "..MATR.M" */
+ 0x41,0x54,0x5F,0x40,0x04,0x5B,0x81,0x0D, /* 00002108 "AT_@.[.." */
+ 0x4D,0x41,0x54,0x52,0x01,0x00,0x20,0x46, /* 00002110 "MATR.. F" */
+ 0x4C,0x47,0x5F,0x01,0x14,0x0D,0x5F,0x4D, /* 00002118 "LG_..._M" */
+ 0x41,0x54,0x00,0xA4,0x96,0x4D,0x41,0x54, /* 00002120 "AT...MAT" */
+ 0x5F,0x00,0x14,0x14,0x5F,0x53,0x54,0x41, /* 00002128 "_..._STA" */
+ 0x00,0xA0,0x08,0x46,0x4C,0x47,0x5F,0xA4, /* 00002130 "...FLG_." */
+ 0x0A,0x0F,0xA1,0x04,0xA4,0x0A,0x09,0x14, /* 00002138 "........" */
+ 0x0A,0x5F,0x45,0x4A,0x30,0x01,0x5B,0x22, /* 00002140 "._EJ0.["" */
+ 0x0A,0xC8,0x5B,0x83,0x47,0x07,0x43,0x36, /* 00002148 "..[.G.C6" */
+ 0x5F,0x5F,0x06,0x10,0xB0,0x00,0x00,0x06, /* 00002150 "__......" */
+ 0x08,0x5F,0x48,0x49,0x44,0x0D,0x41,0x43, /* 00002158 "._HID.AC" */
+ 0x50,0x49,0x30,0x30,0x30,0x37,0x00,0x5B, /* 00002160 "PI0007.[" */
+ 0x80,0x4D,0x41,0x54,0x52,0x00,0x72,0x4D, /* 00002168 ".MATR.rM" */
+ 0x41,0x50,0x41,0x0A,0x30,0x00,0x0A,0x08, /* 00002170 "APA.0..." */
+ 0x5B,0x81,0x0C,0x4D,0x41,0x54,0x52,0x01, /* 00002178 "[..MATR." */
+ 0x4D,0x41,0x54,0x5F,0x40,0x04,0x5B,0x81, /* 00002180 "MAT_@.[." */
+ 0x0D,0x4D,0x41,0x54,0x52,0x01,0x00,0x20, /* 00002188 ".MATR.. " */
+ 0x46,0x4C,0x47,0x5F,0x01,0x14,0x0D,0x5F, /* 00002190 "FLG_..._" */
+ 0x4D,0x41,0x54,0x00,0xA4,0x96,0x4D,0x41, /* 00002198 "MAT...MA" */
+ 0x54,0x5F,0x00,0x14,0x14,0x5F,0x53,0x54, /* 000021A0 "T_..._ST" */
+ 0x41,0x00,0xA0,0x08,0x46,0x4C,0x47,0x5F, /* 000021A8 "A...FLG_" */
+ 0xA4,0x0A,0x0F,0xA1,0x04,0xA4,0x0A,0x09, /* 000021B0 "........" */
+ 0x14,0x0A,0x5F,0x45,0x4A,0x30,0x01,0x5B, /* 000021B8 ".._EJ0.[" */
+ 0x22,0x0A,0xC8,0x5B,0x83,0x47,0x07,0x43, /* 000021C0 ""..[.G.C" */
+ 0x37,0x5F,0x5F,0x07,0x10,0xB0,0x00,0x00, /* 000021C8 "7__....." */
+ 0x06,0x08,0x5F,0x48,0x49,0x44,0x0D,0x41, /* 000021D0 ".._HID.A" */
+ 0x43,0x50,0x49,0x30,0x30,0x30,0x37,0x00, /* 000021D8 "CPI0007." */
+ 0x5B,0x80,0x4D,0x41,0x54,0x52,0x00,0x72, /* 000021E0 "[.MATR.r" */
+ 0x4D,0x41,0x50,0x41,0x0A,0x38,0x00,0x0A, /* 000021E8 "MAPA.8.." */
+ 0x08,0x5B,0x81,0x0C,0x4D,0x41,0x54,0x52, /* 000021F0 ".[..MATR" */
+ 0x01,0x4D,0x41,0x54,0x5F,0x40,0x04,0x5B, /* 000021F8 ".MAT_@.[" */
+ 0x81,0x0D,0x4D,0x41,0x54,0x52,0x01,0x00, /* 00002200 "..MATR.." */
+ 0x20,0x46,0x4C,0x47,0x5F,0x01,0x14,0x0D, /* 00002208 " FLG_..." */
+ 0x5F,0x4D,0x41,0x54,0x00,0xA4,0x96,0x4D, /* 00002210 "_MAT...M" */
+ 0x41,0x54,0x5F,0x00,0x14,0x14,0x5F,0x53, /* 00002218 "AT_..._S" */
+ 0x54,0x41,0x00,0xA0,0x08,0x46,0x4C,0x47, /* 00002220 "TA...FLG" */
+ 0x5F,0xA4,0x0A,0x0F,0xA1,0x04,0xA4,0x0A, /* 00002228 "_......." */
+ 0x09,0x14,0x0A,0x5F,0x45,0x4A,0x30,0x01, /* 00002230 "..._EJ0." */
+ 0x5B,0x22,0x0A,0xC8,0x5B,0x83,0x47,0x07, /* 00002238 "["..[.G." */
+ 0x43,0x38,0x5F,0x5F,0x08,0x10,0xB0,0x00, /* 00002240 "C8__...." */
+ 0x00,0x06,0x08,0x5F,0x48,0x49,0x44,0x0D, /* 00002248 "..._HID." */
+ 0x41,0x43,0x50,0x49,0x30,0x30,0x30,0x37, /* 00002250 "ACPI0007" */
+ 0x00,0x5B,0x80,0x4D,0x41,0x54,0x52,0x00, /* 00002258 ".[.MATR." */
+ 0x72,0x4D,0x41,0x50,0x41,0x0A,0x40,0x00, /* 00002260 "rMAPA.@." */
+ 0x0A,0x08,0x5B,0x81,0x0C,0x4D,0x41,0x54, /* 00002268 "..[..MAT" */
+ 0x52,0x01,0x4D,0x41,0x54,0x5F,0x40,0x04, /* 00002270 "R.MAT_@." */
+ 0x5B,0x81,0x0D,0x4D,0x41,0x54,0x52,0x01, /* 00002278 "[..MATR." */
+ 0x00,0x20,0x46,0x4C,0x47,0x5F,0x01,0x14, /* 00002280 ". FLG_.." */
+ 0x0D,0x5F,0x4D,0x41,0x54,0x00,0xA4,0x96, /* 00002288 "._MAT..." */
+ 0x4D,0x41,0x54,0x5F,0x00,0x14,0x14,0x5F, /* 00002290 "MAT_..._" */
+ 0x53,0x54,0x41,0x00,0xA0,0x08,0x46,0x4C, /* 00002298 "STA...FL" */
+ 0x47,0x5F,0xA4,0x0A,0x0F,0xA1,0x04,0xA4, /* 000022A0 "G_......" */
+ 0x0A,0x09,0x14,0x0A,0x5F,0x45,0x4A,0x30, /* 000022A8 "...._EJ0" */
+ 0x01,0x5B,0x22,0x0A,0xC8,0x5B,0x83,0x47, /* 000022B0 ".["..[.G" */
+ 0x07,0x43,0x39,0x5F,0x5F,0x09,0x10,0xB0, /* 000022B8 ".C9__..." */
+ 0x00,0x00,0x06,0x08,0x5F,0x48,0x49,0x44, /* 000022C0 "...._HID" */
+ 0x0D,0x41,0x43,0x50,0x49,0x30,0x30,0x30, /* 000022C8 ".ACPI000" */
+ 0x37,0x00,0x5B,0x80,0x4D,0x41,0x54,0x52, /* 000022D0 "7.[.MATR" */
+ 0x00,0x72,0x4D,0x41,0x50,0x41,0x0A,0x48, /* 000022D8 ".rMAPA.H" */
+ 0x00,0x0A,0x08,0x5B,0x81,0x0C,0x4D,0x41, /* 000022E0 "...[..MA" */
+ 0x54,0x52,0x01,0x4D,0x41,0x54,0x5F,0x40, /* 000022E8 "TR.MAT_@" */
+ 0x04,0x5B,0x81,0x0D,0x4D,0x41,0x54,0x52, /* 000022F0 ".[..MATR" */
+ 0x01,0x00,0x20,0x46,0x4C,0x47,0x5F,0x01, /* 000022F8 ".. FLG_." */
+ 0x14,0x0D,0x5F,0x4D,0x41,0x54,0x00,0xA4, /* 00002300 ".._MAT.." */
+ 0x96,0x4D,0x41,0x54,0x5F,0x00,0x14,0x14, /* 00002308 ".MAT_..." */
+ 0x5F,0x53,0x54,0x41,0x00,0xA0,0x08,0x46, /* 00002310 "_STA...F" */
+ 0x4C,0x47,0x5F,0xA4,0x0A,0x0F,0xA1,0x04, /* 00002318 "LG_....." */
+ 0xA4,0x0A,0x09,0x14,0x0A,0x5F,0x45,0x4A, /* 00002320 "....._EJ" */
+ 0x30,0x01,0x5B,0x22,0x0A,0xC8,0x5B,0x83, /* 00002328 "0.["..[." */
+ 0x47,0x07,0x43,0x41,0x5F,0x5F,0x0A,0x10, /* 00002330 "G.CA__.." */
+ 0xB0,0x00,0x00,0x06,0x08,0x5F,0x48,0x49, /* 00002338 "....._HI" */
+ 0x44,0x0D,0x41,0x43,0x50,0x49,0x30,0x30, /* 00002340 "D.ACPI00" */
+ 0x30,0x37,0x00,0x5B,0x80,0x4D,0x41,0x54, /* 00002348 "07.[.MAT" */
+ 0x52,0x00,0x72,0x4D,0x41,0x50,0x41,0x0A, /* 00002350 "R.rMAPA." */
+ 0x50,0x00,0x0A,0x08,0x5B,0x81,0x0C,0x4D, /* 00002358 "P...[..M" */
+ 0x41,0x54,0x52,0x01,0x4D,0x41,0x54,0x5F, /* 00002360 "ATR.MAT_" */
+ 0x40,0x04,0x5B,0x81,0x0D,0x4D,0x41,0x54, /* 00002368 "@.[..MAT" */
+ 0x52,0x01,0x00,0x20,0x46,0x4C,0x47,0x5F, /* 00002370 "R.. FLG_" */
+ 0x01,0x14,0x0D,0x5F,0x4D,0x41,0x54,0x00, /* 00002378 "..._MAT." */
+ 0xA4,0x96,0x4D,0x41,0x54,0x5F,0x00,0x14, /* 00002380 "..MAT_.." */
+ 0x14,0x5F,0x53,0x54,0x41,0x00,0xA0,0x08, /* 00002388 "._STA..." */
+ 0x46,0x4C,0x47,0x5F,0xA4,0x0A,0x0F,0xA1, /* 00002390 "FLG_...." */
+ 0x04,0xA4,0x0A,0x09,0x14,0x0A,0x5F,0x45, /* 00002398 "......_E" */
+ 0x4A,0x30,0x01,0x5B,0x22,0x0A,0xC8,0x5B, /* 000023A0 "J0.["..[" */
+ 0x83,0x47,0x07,0x43,0x42,0x5F,0x5F,0x0B, /* 000023A8 ".G.CB__." */
+ 0x10,0xB0,0x00,0x00,0x06,0x08,0x5F,0x48, /* 000023B0 "......_H" */
+ 0x49,0x44,0x0D,0x41,0x43,0x50,0x49,0x30, /* 000023B8 "ID.ACPI0" */
+ 0x30,0x30,0x37,0x00,0x5B,0x80,0x4D,0x41, /* 000023C0 "007.[.MA" */
+ 0x54,0x52,0x00,0x72,0x4D,0x41,0x50,0x41, /* 000023C8 "TR.rMAPA" */
+ 0x0A,0x58,0x00,0x0A,0x08,0x5B,0x81,0x0C, /* 000023D0 ".X...[.." */
+ 0x4D,0x41,0x54,0x52,0x01,0x4D,0x41,0x54, /* 000023D8 "MATR.MAT" */
+ 0x5F,0x40,0x04,0x5B,0x81,0x0D,0x4D,0x41, /* 000023E0 "_@.[..MA" */
+ 0x54,0x52,0x01,0x00,0x20,0x46,0x4C,0x47, /* 000023E8 "TR.. FLG" */
+ 0x5F,0x01,0x14,0x0D,0x5F,0x4D,0x41,0x54, /* 000023F0 "_..._MAT" */
+ 0x00,0xA4,0x96,0x4D,0x41,0x54,0x5F,0x00, /* 000023F8 "...MAT_." */
+ 0x14,0x14,0x5F,0x53,0x54,0x41,0x00,0xA0, /* 00002400 ".._STA.." */
+ 0x08,0x46,0x4C,0x47,0x5F,0xA4,0x0A,0x0F, /* 00002408 ".FLG_..." */
+ 0xA1,0x04,0xA4,0x0A,0x09,0x14,0x0A,0x5F, /* 00002410 "......._" */
+ 0x45,0x4A,0x30,0x01,0x5B,0x22,0x0A,0xC8, /* 00002418 "EJ0.[".." */
+ 0x5B,0x83,0x47,0x07,0x43,0x43,0x5F,0x5F, /* 00002420 "[.G.CC__" */
+ 0x0C,0x10,0xB0,0x00,0x00,0x06,0x08,0x5F, /* 00002428 "......._" */
+ 0x48,0x49,0x44,0x0D,0x41,0x43,0x50,0x49, /* 00002430 "HID.ACPI" */
+ 0x30,0x30,0x30,0x37,0x00,0x5B,0x80,0x4D, /* 00002438 "0007.[.M" */
+ 0x41,0x54,0x52,0x00,0x72,0x4D,0x41,0x50, /* 00002440 "ATR.rMAP" */
+ 0x41,0x0A,0x60,0x00,0x0A,0x08,0x5B,0x81, /* 00002448 "A.`...[." */
+ 0x0C,0x4D,0x41,0x54,0x52,0x01,0x4D,0x41, /* 00002450 ".MATR.MA" */
+ 0x54,0x5F,0x40,0x04,0x5B,0x81,0x0D,0x4D, /* 00002458 "T_@.[..M" */
+ 0x41,0x54,0x52,0x01,0x00,0x20,0x46,0x4C, /* 00002460 "ATR.. FL" */
+ 0x47,0x5F,0x01,0x14,0x0D,0x5F,0x4D,0x41, /* 00002468 "G_..._MA" */
+ 0x54,0x00,0xA4,0x96,0x4D,0x41,0x54,0x5F, /* 00002470 "T...MAT_" */
+ 0x00,0x14,0x14,0x5F,0x53,0x54,0x41,0x00, /* 00002478 "..._STA." */
+ 0xA0,0x08,0x46,0x4C,0x47,0x5F,0xA4,0x0A, /* 00002480 "..FLG_.." */
+ 0x0F,0xA1,0x04,0xA4,0x0A,0x09,0x14,0x0A, /* 00002488 "........" */
+ 0x5F,0x45,0x4A,0x30,0x01,0x5B,0x22,0x0A, /* 00002490 "_EJ0.["." */
+ 0xC8,0x5B,0x83,0x47,0x07,0x43,0x44,0x5F, /* 00002498 ".[.G.CD_" */
+ 0x5F,0x0D,0x10,0xB0,0x00,0x00,0x06,0x08, /* 000024A0 "_......." */
+ 0x5F,0x48,0x49,0x44,0x0D,0x41,0x43,0x50, /* 000024A8 "_HID.ACP" */
+ 0x49,0x30,0x30,0x30,0x37,0x00,0x5B,0x80, /* 000024B0 "I0007.[." */
+ 0x4D,0x41,0x54,0x52,0x00,0x72,0x4D,0x41, /* 000024B8 "MATR.rMA" */
+ 0x50,0x41,0x0A,0x68,0x00,0x0A,0x08,0x5B, /* 000024C0 "PA.h...[" */
+ 0x81,0x0C,0x4D,0x41,0x54,0x52,0x01,0x4D, /* 000024C8 "..MATR.M" */
+ 0x41,0x54,0x5F,0x40,0x04,0x5B,0x81,0x0D, /* 000024D0 "AT_@.[.." */
+ 0x4D,0x41,0x54,0x52,0x01,0x00,0x20,0x46, /* 000024D8 "MATR.. F" */
+ 0x4C,0x47,0x5F,0x01,0x14,0x0D,0x5F,0x4D, /* 000024E0 "LG_..._M" */
+ 0x41,0x54,0x00,0xA4,0x96,0x4D,0x41,0x54, /* 000024E8 "AT...MAT" */
+ 0x5F,0x00,0x14,0x14,0x5F,0x53,0x54,0x41, /* 000024F0 "_..._STA" */
+ 0x00,0xA0,0x08,0x46,0x4C,0x47,0x5F,0xA4, /* 000024F8 "...FLG_." */
+ 0x0A,0x0F,0xA1,0x04,0xA4,0x0A,0x09,0x14, /* 00002500 "........" */
+ 0x0A,0x5F,0x45,0x4A,0x30,0x01,0x5B,0x22, /* 00002508 "._EJ0.["" */
+ 0x0A,0xC8,0x5B,0x83,0x47,0x07,0x43,0x45, /* 00002510 "..[.G.CE" */
+ 0x5F,0x5F,0x0E,0x10,0xB0,0x00,0x00,0x06, /* 00002518 "__......" */
+ 0x08,0x5F,0x48,0x49,0x44,0x0D,0x41,0x43, /* 00002520 "._HID.AC" */
+ 0x50,0x49,0x30,0x30,0x30,0x37,0x00,0x5B, /* 00002528 "PI0007.[" */
+ 0x80,0x4D,0x41,0x54,0x52,0x00,0x72,0x4D, /* 00002530 ".MATR.rM" */
+ 0x41,0x50,0x41,0x0A,0x70,0x00,0x0A,0x08, /* 00002538 "APA.p..." */
+ 0x5B,0x81,0x0C,0x4D,0x41,0x54,0x52,0x01, /* 00002540 "[..MATR." */
+ 0x4D,0x41,0x54,0x5F,0x40,0x04,0x5B,0x81, /* 00002548 "MAT_@.[." */
+ 0x0D,0x4D,0x41,0x54,0x52,0x01,0x00,0x20, /* 00002550 ".MATR.. " */
+ 0x46,0x4C,0x47,0x5F,0x01,0x14,0x0D,0x5F, /* 00002558 "FLG_..._" */
+ 0x4D,0x41,0x54,0x00,0xA4,0x96,0x4D,0x41, /* 00002560 "MAT...MA" */
+ 0x54,0x5F,0x00,0x14,0x14,0x5F,0x53,0x54, /* 00002568 "T_..._ST" */
+ 0x41,0x00,0xA0,0x08,0x46,0x4C,0x47,0x5F, /* 00002570 "A...FLG_" */
+ 0xA4,0x0A,0x0F,0xA1,0x04,0xA4,0x0A,0x09, /* 00002578 "........" */
+ 0x14,0x0A,0x5F,0x45,0x4A,0x30,0x01,0x5B, /* 00002580 ".._EJ0.[" */
+ 0x22,0x0A,0xC8,0x14,0x4C,0x46,0x4E,0x54, /* 00002588 ""...LFNT" */
+ 0x46,0x59,0x02,0xA0,0x49,0x04,0x93,0x68, /* 00002590 "FY..I..h" */
+ 0x00,0xA0,0x43,0x04,0x92,0x93,0x69,0x5E, /* 00002598 "..C...i^" */
+ 0x2E,0x43,0x30,0x5F,0x5F,0x46,0x4C,0x47, /* 000025A0 ".C0__FLG" */
+ 0x5F,0x70,0x69,0x5E,0x2E,0x43,0x30,0x5F, /* 000025A8 "_pi^.C0_" */
+ 0x5F,0x46,0x4C,0x47,0x5F,0xA0,0x14,0x93, /* 000025B0 "_FLG_..." */
+ 0x69,0x01,0x86,0x43,0x30,0x5F,0x5F,0x01, /* 000025B8 "i..C0__." */
+ 0x74,0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53, /* 000025C0 "tMSU_.MS" */
+ 0x55,0x5F,0xA1,0x12,0x86,0x43,0x30,0x5F, /* 000025C8 "U_...C0_" */
+ 0x5F,0x0A,0x03,0x72,0x4D,0x53,0x55,0x5F, /* 000025D0 "_..rMSU_" */
+ 0x01,0x4D,0x53,0x55,0x5F,0xA0,0x49,0x04, /* 000025D8 ".MSU_.I." */
+ 0x93,0x68,0x01,0xA0,0x43,0x04,0x92,0x93, /* 000025E0 ".h..C..." */
+ 0x69,0x5E,0x2E,0x43,0x31,0x5F,0x5F,0x46, /* 000025E8 "i^.C1__F" */
+ 0x4C,0x47,0x5F,0x70,0x69,0x5E,0x2E,0x43, /* 000025F0 "LG_pi^.C" */
+ 0x31,0x5F,0x5F,0x46,0x4C,0x47,0x5F,0xA0, /* 000025F8 "1__FLG_." */
+ 0x14,0x93,0x69,0x01,0x86,0x43,0x31,0x5F, /* 00002600 "..i..C1_" */
+ 0x5F,0x01,0x74,0x4D,0x53,0x55,0x5F,0x01, /* 00002608 "_.tMSU_." */
+ 0x4D,0x53,0x55,0x5F,0xA1,0x12,0x86,0x43, /* 00002610 "MSU_...C" */
+ 0x31,0x5F,0x5F,0x0A,0x03,0x72,0x4D,0x53, /* 00002618 "1__..rMS" */
+ 0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA0, /* 00002620 "U_.MSU_." */
+ 0x4A,0x04,0x93,0x68,0x0A,0x02,0xA0,0x43, /* 00002628 "J..h...C" */
+ 0x04,0x92,0x93,0x69,0x5E,0x2E,0x43,0x32, /* 00002630 "...i^.C2" */
+ 0x5F,0x5F,0x46,0x4C,0x47,0x5F,0x70,0x69, /* 00002638 "__FLG_pi" */
+ 0x5E,0x2E,0x43,0x32,0x5F,0x5F,0x46,0x4C, /* 00002640 "^.C2__FL" */
+ 0x47,0x5F,0xA0,0x14,0x93,0x69,0x01,0x86, /* 00002648 "G_...i.." */
+ 0x43,0x32,0x5F,0x5F,0x01,0x74,0x4D,0x53, /* 00002650 "C2__.tMS" */
+ 0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA1, /* 00002658 "U_.MSU_." */
+ 0x12,0x86,0x43,0x32,0x5F,0x5F,0x0A,0x03, /* 00002660 "..C2__.." */
+ 0x72,0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53, /* 00002668 "rMSU_.MS" */
+ 0x55,0x5F,0xA0,0x4A,0x04,0x93,0x68,0x0A, /* 00002670 "U_.J..h." */
+ 0x03,0xA0,0x43,0x04,0x92,0x93,0x69,0x5E, /* 00002678 "..C...i^" */
+ 0x2E,0x43,0x33,0x5F,0x5F,0x46,0x4C,0x47, /* 00002680 ".C3__FLG" */
+ 0x5F,0x70,0x69,0x5E,0x2E,0x43,0x33,0x5F, /* 00002688 "_pi^.C3_" */
+ 0x5F,0x46,0x4C,0x47,0x5F,0xA0,0x14,0x93, /* 00002690 "_FLG_..." */
+ 0x69,0x01,0x86,0x43,0x33,0x5F,0x5F,0x01, /* 00002698 "i..C3__." */
+ 0x74,0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53, /* 000026A0 "tMSU_.MS" */
+ 0x55,0x5F,0xA1,0x12,0x86,0x43,0x33,0x5F, /* 000026A8 "U_...C3_" */
+ 0x5F,0x0A,0x03,0x72,0x4D,0x53,0x55,0x5F, /* 000026B0 "_..rMSU_" */
+ 0x01,0x4D,0x53,0x55,0x5F,0xA0,0x4A,0x04, /* 000026B8 ".MSU_.J." */
+ 0x93,0x68,0x0A,0x04,0xA0,0x43,0x04,0x92, /* 000026C0 ".h...C.." */
+ 0x93,0x69,0x5E,0x2E,0x43,0x34,0x5F,0x5F, /* 000026C8 ".i^.C4__" */
+ 0x46,0x4C,0x47,0x5F,0x70,0x69,0x5E,0x2E, /* 000026D0 "FLG_pi^." */
+ 0x43,0x34,0x5F,0x5F,0x46,0x4C,0x47,0x5F, /* 000026D8 "C4__FLG_" */
+ 0xA0,0x14,0x93,0x69,0x01,0x86,0x43,0x34, /* 000026E0 "...i..C4" */
+ 0x5F,0x5F,0x01,0x74,0x4D,0x53,0x55,0x5F, /* 000026E8 "__.tMSU_" */
+ 0x01,0x4D,0x53,0x55,0x5F,0xA1,0x12,0x86, /* 000026F0 ".MSU_..." */
+ 0x43,0x34,0x5F,0x5F,0x0A,0x03,0x72,0x4D, /* 000026F8 "C4__..rM" */
+ 0x53,0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F, /* 00002700 "SU_.MSU_" */
+ 0xA0,0x4A,0x04,0x93,0x68,0x0A,0x05,0xA0, /* 00002708 ".J..h..." */
+ 0x43,0x04,0x92,0x93,0x69,0x5E,0x2E,0x43, /* 00002710 "C...i^.C" */
+ 0x35,0x5F,0x5F,0x46,0x4C,0x47,0x5F,0x70, /* 00002718 "5__FLG_p" */
+ 0x69,0x5E,0x2E,0x43,0x35,0x5F,0x5F,0x46, /* 00002720 "i^.C5__F" */
+ 0x4C,0x47,0x5F,0xA0,0x14,0x93,0x69,0x01, /* 00002728 "LG_...i." */
+ 0x86,0x43,0x35,0x5F,0x5F,0x01,0x74,0x4D, /* 00002730 ".C5__.tM" */
+ 0x53,0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F, /* 00002738 "SU_.MSU_" */
+ 0xA1,0x12,0x86,0x43,0x35,0x5F,0x5F,0x0A, /* 00002740 "...C5__." */
+ 0x03,0x72,0x4D,0x53,0x55,0x5F,0x01,0x4D, /* 00002748 ".rMSU_.M" */
+ 0x53,0x55,0x5F,0xA0,0x4A,0x04,0x93,0x68, /* 00002750 "SU_.J..h" */
+ 0x0A,0x06,0xA0,0x43,0x04,0x92,0x93,0x69, /* 00002758 "...C...i" */
+ 0x5E,0x2E,0x43,0x36,0x5F,0x5F,0x46,0x4C, /* 00002760 "^.C6__FL" */
+ 0x47,0x5F,0x70,0x69,0x5E,0x2E,0x43,0x36, /* 00002768 "G_pi^.C6" */
+ 0x5F,0x5F,0x46,0x4C,0x47,0x5F,0xA0,0x14, /* 00002770 "__FLG_.." */
+ 0x93,0x69,0x01,0x86,0x43,0x36,0x5F,0x5F, /* 00002778 ".i..C6__" */
+ 0x01,0x74,0x4D,0x53,0x55,0x5F,0x01,0x4D, /* 00002780 ".tMSU_.M" */
+ 0x53,0x55,0x5F,0xA1,0x12,0x86,0x43,0x36, /* 00002788 "SU_...C6" */
+ 0x5F,0x5F,0x0A,0x03,0x72,0x4D,0x53,0x55, /* 00002790 "__..rMSU" */
+ 0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA0,0x4A, /* 00002798 "_.MSU_.J" */
+ 0x04,0x93,0x68,0x0A,0x07,0xA0,0x43,0x04, /* 000027A0 "..h...C." */
+ 0x92,0x93,0x69,0x5E,0x2E,0x43,0x37,0x5F, /* 000027A8 "..i^.C7_" */
+ 0x5F,0x46,0x4C,0x47,0x5F,0x70,0x69,0x5E, /* 000027B0 "_FLG_pi^" */
+ 0x2E,0x43,0x37,0x5F,0x5F,0x46,0x4C,0x47, /* 000027B8 ".C7__FLG" */
+ 0x5F,0xA0,0x14,0x93,0x69,0x01,0x86,0x43, /* 000027C0 "_...i..C" */
+ 0x37,0x5F,0x5F,0x01,0x74,0x4D,0x53,0x55, /* 000027C8 "7__.tMSU" */
+ 0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA1,0x12, /* 000027D0 "_.MSU_.." */
+ 0x86,0x43,0x37,0x5F,0x5F,0x0A,0x03,0x72, /* 000027D8 ".C7__..r" */
+ 0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53,0x55, /* 000027E0 "MSU_.MSU" */
+ 0x5F,0xA0,0x4A,0x04,0x93,0x68,0x0A,0x08, /* 000027E8 "_.J..h.." */
+ 0xA0,0x43,0x04,0x92,0x93,0x69,0x5E,0x2E, /* 000027F0 ".C...i^." */
+ 0x43,0x38,0x5F,0x5F,0x46,0x4C,0x47,0x5F, /* 000027F8 "C8__FLG_" */
+ 0x70,0x69,0x5E,0x2E,0x43,0x38,0x5F,0x5F, /* 00002800 "pi^.C8__" */
+ 0x46,0x4C,0x47,0x5F,0xA0,0x14,0x93,0x69, /* 00002808 "FLG_...i" */
+ 0x01,0x86,0x43,0x38,0x5F,0x5F,0x01,0x74, /* 00002810 "..C8__.t" */
+ 0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53,0x55, /* 00002818 "MSU_.MSU" */
+ 0x5F,0xA1,0x12,0x86,0x43,0x38,0x5F,0x5F, /* 00002820 "_...C8__" */
+ 0x0A,0x03,0x72,0x4D,0x53,0x55,0x5F,0x01, /* 00002828 "..rMSU_." */
+ 0x4D,0x53,0x55,0x5F,0xA0,0x4A,0x04,0x93, /* 00002830 "MSU_.J.." */
+ 0x68,0x0A,0x09,0xA0,0x43,0x04,0x92,0x93, /* 00002838 "h...C..." */
+ 0x69,0x5E,0x2E,0x43,0x39,0x5F,0x5F,0x46, /* 00002840 "i^.C9__F" */
+ 0x4C,0x47,0x5F,0x70,0x69,0x5E,0x2E,0x43, /* 00002848 "LG_pi^.C" */
+ 0x39,0x5F,0x5F,0x46,0x4C,0x47,0x5F,0xA0, /* 00002850 "9__FLG_." */
+ 0x14,0x93,0x69,0x01,0x86,0x43,0x39,0x5F, /* 00002858 "..i..C9_" */
+ 0x5F,0x01,0x74,0x4D,0x53,0x55,0x5F,0x01, /* 00002860 "_.tMSU_." */
+ 0x4D,0x53,0x55,0x5F,0xA1,0x12,0x86,0x43, /* 00002868 "MSU_...C" */
+ 0x39,0x5F,0x5F,0x0A,0x03,0x72,0x4D,0x53, /* 00002870 "9__..rMS" */
+ 0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA0, /* 00002878 "U_.MSU_." */
+ 0x4A,0x04,0x93,0x68,0x0A,0x0A,0xA0,0x43, /* 00002880 "J..h...C" */
+ 0x04,0x92,0x93,0x69,0x5E,0x2E,0x43,0x41, /* 00002888 "...i^.CA" */
+ 0x5F,0x5F,0x46,0x4C,0x47,0x5F,0x70,0x69, /* 00002890 "__FLG_pi" */
+ 0x5E,0x2E,0x43,0x41,0x5F,0x5F,0x46,0x4C, /* 00002898 "^.CA__FL" */
+ 0x47,0x5F,0xA0,0x14,0x93,0x69,0x01,0x86, /* 000028A0 "G_...i.." */
+ 0x43,0x41,0x5F,0x5F,0x01,0x74,0x4D,0x53, /* 000028A8 "CA__.tMS" */
+ 0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA1, /* 000028B0 "U_.MSU_." */
+ 0x12,0x86,0x43,0x41,0x5F,0x5F,0x0A,0x03, /* 000028B8 "..CA__.." */
+ 0x72,0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53, /* 000028C0 "rMSU_.MS" */
+ 0x55,0x5F,0xA0,0x4A,0x04,0x93,0x68,0x0A, /* 000028C8 "U_.J..h." */
+ 0x0B,0xA0,0x43,0x04,0x92,0x93,0x69,0x5E, /* 000028D0 "..C...i^" */
+ 0x2E,0x43,0x42,0x5F,0x5F,0x46,0x4C,0x47, /* 000028D8 ".CB__FLG" */
+ 0x5F,0x70,0x69,0x5E,0x2E,0x43,0x42,0x5F, /* 000028E0 "_pi^.CB_" */
+ 0x5F,0x46,0x4C,0x47,0x5F,0xA0,0x14,0x93, /* 000028E8 "_FLG_..." */
+ 0x69,0x01,0x86,0x43,0x42,0x5F,0x5F,0x01, /* 000028F0 "i..CB__." */
+ 0x74,0x4D,0x53,0x55,0x5F,0x01,0x4D,0x53, /* 000028F8 "tMSU_.MS" */
+ 0x55,0x5F,0xA1,0x12,0x86,0x43,0x42,0x5F, /* 00002900 "U_...CB_" */
+ 0x5F,0x0A,0x03,0x72,0x4D,0x53,0x55,0x5F, /* 00002908 "_..rMSU_" */
+ 0x01,0x4D,0x53,0x55,0x5F,0xA0,0x4A,0x04, /* 00002910 ".MSU_.J." */
+ 0x93,0x68,0x0A,0x0C,0xA0,0x43,0x04,0x92, /* 00002918 ".h...C.." */
+ 0x93,0x69,0x5E,0x2E,0x43,0x43,0x5F,0x5F, /* 00002920 ".i^.CC__" */
+ 0x46,0x4C,0x47,0x5F,0x70,0x69,0x5E,0x2E, /* 00002928 "FLG_pi^." */
+ 0x43,0x43,0x5F,0x5F,0x46,0x4C,0x47,0x5F, /* 00002930 "CC__FLG_" */
+ 0xA0,0x14,0x93,0x69,0x01,0x86,0x43,0x43, /* 00002938 "...i..CC" */
+ 0x5F,0x5F,0x01,0x74,0x4D,0x53,0x55,0x5F, /* 00002940 "__.tMSU_" */
+ 0x01,0x4D,0x53,0x55,0x5F,0xA1,0x12,0x86, /* 00002948 ".MSU_..." */
+ 0x43,0x43,0x5F,0x5F,0x0A,0x03,0x72,0x4D, /* 00002950 "CC__..rM" */
+ 0x53,0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F, /* 00002958 "SU_.MSU_" */
+ 0xA0,0x4A,0x04,0x93,0x68,0x0A,0x0D,0xA0, /* 00002960 ".J..h..." */
+ 0x43,0x04,0x92,0x93,0x69,0x5E,0x2E,0x43, /* 00002968 "C...i^.C" */
+ 0x44,0x5F,0x5F,0x46,0x4C,0x47,0x5F,0x70, /* 00002970 "D__FLG_p" */
+ 0x69,0x5E,0x2E,0x43,0x44,0x5F,0x5F,0x46, /* 00002978 "i^.CD__F" */
+ 0x4C,0x47,0x5F,0xA0,0x14,0x93,0x69,0x01, /* 00002980 "LG_...i." */
+ 0x86,0x43,0x44,0x5F,0x5F,0x01,0x74,0x4D, /* 00002988 ".CD__.tM" */
+ 0x53,0x55,0x5F,0x01,0x4D,0x53,0x55,0x5F, /* 00002990 "SU_.MSU_" */
+ 0xA1,0x12,0x86,0x43,0x44,0x5F,0x5F,0x0A, /* 00002998 "...CD__." */
+ 0x03,0x72,0x4D,0x53,0x55,0x5F,0x01,0x4D, /* 000029A0 ".rMSU_.M" */
+ 0x53,0x55,0x5F,0xA0,0x4A,0x04,0x93,0x68, /* 000029A8 "SU_.J..h" */
+ 0x0A,0x0E,0xA0,0x43,0x04,0x92,0x93,0x69, /* 000029B0 "...C...i" */
+ 0x5E,0x2E,0x43,0x45,0x5F,0x5F,0x46,0x4C, /* 000029B8 "^.CE__FL" */
+ 0x47,0x5F,0x70,0x69,0x5E,0x2E,0x43,0x45, /* 000029C0 "G_pi^.CE" */
+ 0x5F,0x5F,0x46,0x4C,0x47,0x5F,0xA0,0x14, /* 000029C8 "__FLG_.." */
+ 0x93,0x69,0x01,0x86,0x43,0x45,0x5F,0x5F, /* 000029D0 ".i..CE__" */
+ 0x01,0x74,0x4D,0x53,0x55,0x5F,0x01,0x4D, /* 000029D8 ".tMSU_.M" */
+ 0x53,0x55,0x5F,0xA1,0x12,0x86,0x43,0x45, /* 000029E0 "SU_...CE" */
+ 0x5F,0x5F,0x0A,0x03,0x72,0x4D,0x53,0x55, /* 000029E8 "__..rMSU" */
+ 0x5F,0x01,0x4D,0x53,0x55,0x5F,0xA4,0x01, /* 000029F0 "_.MSU_.." */
+ 0x5B,0x80,0x50,0x52,0x53,0x54,0x01,0x0B, /* 000029F8 "[.PRST.." */
+ 0x00,0xAF,0x0A,0x20,0x5B,0x81,0x0C,0x50, /* 00002A00 "... [..P" */
+ 0x52,0x53,0x54,0x01,0x50,0x52,0x53,0x5F, /* 00002A08 "RST.PRS_" */
+ 0x40,0x10,0x14,0x4A,0x06,0x50,0x52,0x53, /* 00002A10 "@..J.PRS" */
+ 0x43,0x00,0x70,0x50,0x52,0x53,0x5F,0x63, /* 00002A18 "C.pPRS_c" */
+ 0x70,0x00,0x60,0xA2,0x2F,0x95,0x60,0x50, /* 00002A20 "p.`./.`P" */
+ 0x42,0x59,0x54,0x70,0x00,0x61,0x70,0x83, /* 00002A28 "BYTp.ap." */
+ 0x88,0x63,0x60,0x00,0x62,0xA2,0x1B,0x95, /* 00002A30 ".c`.b..." */
+ 0x61,0x0A,0x08,0x4E,0x54,0x46,0x59,0x72, /* 00002A38 "a..NTFYr" */
+ 0x77,0x60,0x0A,0x08,0x00,0x61,0x00,0x7B, /* 00002A40 "w`...a.{" */
+ 0x62,0x01,0x00,0x7A,0x62,0x01,0x62,0x75, /* 00002A48 "b..zb.bu" */
+ 0x61,0x75,0x60,0x70,0x00,0x61,0x70,0x83, /* 00002A50 "au`p.ap." */
+ 0x88,0x63,0x60,0x00,0x62,0xA2,0x1D,0x95, /* 00002A58 ".c`.b..." */
+ 0x61,0x50,0x42,0x49,0x54,0x4E,0x54,0x46, /* 00002A60 "aPBITNTF" */
+ 0x59,0x72,0x77,0x60,0x0A,0x08,0x00,0x61, /* 00002A68 "Yrw`...a" */
+ 0x00,0x7B,0x62,0x01,0x00,0x7A,0x62,0x01, /* 00002A70 ".{b..zb." */
+ 0x62,0x75,0x61,0xA4,0x01,
};
diff --git a/src/acpi.c b/src/acpi.c
index f613b03..037da46 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -344,6 +344,9 @@ build_fadt(int bdf)
return fadt;
}
+u32 madt_csum_addr, madt_lapic0_addr;
+u32 max_cpus_byte, max_cpus_bit;
+
static void*
build_madt(void)
{
@@ -360,6 +363,10 @@ build_madt(void)
madt->local_apic_address = cpu_to_le32(BUILD_APIC_ADDR);
madt->flags = cpu_to_le32(1);
struct madt_processor_apic *apic = (void*)&madt[1];
+ madt_csum_addr = (u32)&madt->checksum;
+ madt_lapic0_addr = (u32)apic;
+ max_cpus_byte = MaxCountCPUs / 8;
+ max_cpus_bit = MaxCountCPUs % 8;
int i;
for (i=0; i<MaxCountCPUs; i++) {
apic->type = APIC_PROCESSOR;
diff --git a/src/biosvar.h b/src/biosvar.h
index b6e061b..57dd86b 100644
--- a/src/biosvar.h
+++ b/src/biosvar.h
@@ -11,6 +11,20 @@
#include "config.h" // CONFIG_*
#include "disk.h" // struct chs_s
+/* *****************************************************************
+ * use bios_info to enable dsdt get run-time madt and cpu info,
+ * and to avoid more hardcode magic number.
+ *******************************************************************/
+#define BIOS_INFO_PHYSICAL_ADDRESS 0x000EA000
+struct bios_info {
+ u32 madt_csum_addr; /* address of MADT checksum */
+ u32 madt_lapic0_addr; /* address of first MADT LAPIC struct */
+ u32 max_cpus_byte; /* max cpus bitmap bytes */
+ u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
+};
+
+extern u32 madt_csum_addr, madt_lapic0_addr;
+extern u32 max_cpus_byte, max_cpus_bit;
/****************************************************************
* Interupt vector table
diff --git a/src/post.c b/src/post.c
index fb3b37f..8e30a57 100644
--- a/src/post.c
+++ b/src/post.c
@@ -161,6 +161,18 @@ init_bios_tables(void)
acpi_bios_init();
}
+static void init_bios_info(void)
+{
+ struct bios_info *bios_info;
+
+ bios_info = (struct bios_info *)BIOS_INFO_PHYSICAL_ADDRESS;
+ memset(bios_info, 0, sizeof(*bios_info));
+ bios_info->madt_csum_addr = madt_csum_addr;
+ bios_info->madt_lapic0_addr = madt_lapic0_addr;
+ bios_info->max_cpus_byte = max_cpus_byte;
+ bios_info->max_cpus_bit = max_cpus_bit;
+}
+
// Main setup code.
static void
post(void)
@@ -195,6 +207,7 @@ post(void)
kbd_setup();
mouse_setup();
init_bios_tables();
+ init_bios_info();
// Run vga option rom (if running synchronously)
if (!CONFIG_THREADS || !CONFIG_THREAD_OPTIONROMS)
--
1.6.5.6
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-21 11:48 [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt Liu, Jinsong
@ 2010-01-21 12:44 ` Gleb Natapov
2010-01-22 2:15 ` Liu, Jinsong
0 siblings, 1 reply; 12+ messages in thread
From: Gleb Natapov @ 2010-01-21 12:44 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 22 Jan 2010 03:18:46 +0800
> Subject: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
>
> 1. setup madt bios_info structure, so that static dsdt get
> run-time madt info like checksum address, lapic address,
> max cpu numbers, with least hardcode magic number (realmode
> address of bios_info).
> 2. setup vcpu add/remove dsdt infrastructure, including processor
> related acpi objects and control methods. vcpu add/remove will
> trigger SCI and then control method _L02. By matching madt, vcpu
> number and add/remove action were found, then by notify control
> method, it will notify OS acpi driver.
>
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
It looks like AML code is a port of what we had in BOCHS bios with minor
changes. Can you detail what is changed and why for easy review please?
And this still doesn't work with Windows I assume.
> ---
> src/acpi-dsdt.dsl | 131 ++++++++++++++++-
> src/acpi-dsdt.hex | 441 ++++++++++++++++++++++++++++++++++++++++++++++++++---
> src/acpi.c | 7 +
> src/biosvar.h | 14 ++
> src/post.c | 13 ++
> 5 files changed, 582 insertions(+), 24 deletions(-)
>
> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> index cc31112..ed78489 100644
> --- a/src/acpi-dsdt.dsl
> +++ b/src/acpi-dsdt.dsl
> @@ -700,8 +700,11 @@ DefinitionBlock (
> Return (0x01)
>
> }
> + /*
> + * _L02 method for CPU notification
> + */
> Method(_L02) {
> - Return(0x01)
> + Return(\_PR.PRSC())
> }
> Method(_L03) {
> Return(0x01)
> @@ -744,4 +747,130 @@ DefinitionBlock (
> }
> }
>
> +
> + Scope (\_PR)
> + {
> + /* BIOS_INFO_PHYSICAL_ADDRESS == 0xEA000 */
> + OperationRegion(BIOS, SystemMemory, 0xEA000, 16)
> + Field(BIOS, DwordAcc, NoLock, Preserve)
> + {
> + MSUA, 32, /* MADT checksum address */
> + MAPA, 32, /* MADT LAPIC0 address */
> + PBYT, 32, /* bytes of max vcpus bitmap */
> + PBIT, 32 /* bits of last byte of max vcpus bitmap */
Why do you need PBYT/PBIT? Adds complexity for no apparent reason.
> + }
> +
> + OperationRegion(MSUM, SystemMemory, MSUA, 1)
> + Field(MSUM, ByteAcc, NoLock, Preserve)
> + {
> + MSU, 8 /* MADT checksum */
> + }
> +
> + #define gen_processor(nr, name) \
> + Processor (C##name, nr, 0x0000b010, 0x06) { \
> + Name (_HID, "ACPI0007") \
> + OperationRegion(MATR, SystemMemory, Add(MAPA, Multiply(nr,8)), 8) \
> + Field (MATR, ByteAcc, NoLock, Preserve) \
> + { \
> + MAT, 64 \
> + } \
> + Field (MATR, ByteAcc, NoLock, Preserve) \
> + { \
> + Offset(4), \
> + FLG, 1 \
> + } \
> + Method(_MAT, 0) { \
> + Return(ToBuffer(MAT)) \
> + } \
> + Method (_STA) { \
> + If (FLG) { Return(0xF) } Else { Return(0x9) } \
> + } \
> + Method (_EJ0, 1, NotSerialized) { \
> + Sleep (0xC8) \
> + } \
Why _EJ0 is needed?
> + } \
> +
> + gen_processor(0, 0)
> + gen_processor(1, 1)
> + gen_processor(2, 2)
> + gen_processor(3, 3)
> + gen_processor(4, 4)
> + gen_processor(5, 5)
> + gen_processor(6, 6)
> + gen_processor(7, 7)
> + gen_processor(8, 8)
> + gen_processor(9, 9)
> + gen_processor(10, A)
> + gen_processor(11, B)
> + gen_processor(12, C)
> + gen_processor(13, D)
> + gen_processor(14, E)
> +
> +
> + Method (NTFY, 2) {
> + #define gen_ntfy(nr) \
> + If (LEqual(Arg0, 0x##nr)) { \
> + If (LNotEqual(Arg1, \_PR.C##nr.FLG)) { \
> + Store (Arg1, \_PR.C##nr.FLG) \
> + If (LEqual(Arg1, 1)) { \
> + Notify(C##nr, 1) \
> + Subtract(\_PR.MSU, 1, \_PR.MSU) \
> + } Else { \
> + Notify(C##nr, 3) \
> + Add(\_PR.MSU, 1, \_PR.MSU) \
> + } \
> + } \
> + }
> +
> + gen_ntfy(0)
> + gen_ntfy(1)
> + gen_ntfy(2)
> + gen_ntfy(3)
> + gen_ntfy(4)
> + gen_ntfy(5)
> + gen_ntfy(6)
> + gen_ntfy(7)
> + gen_ntfy(8)
> + gen_ntfy(9)
> + gen_ntfy(A)
> + gen_ntfy(B)
> + gen_ntfy(C)
> + gen_ntfy(D)
> + gen_ntfy(E)
> +
> + Return(One)
> + }
> +
> +
> + OperationRegion(PRST, SystemIO, 0xaf00, 32)
> + Field (PRST, ByteAcc, NoLock, Preserve)
> + {
> + PRS, 256
> + }
> +
> + Method(PRSC, 0) {
> + Store(PRS, Local3)
> + Store(Zero, Local0)
> + While(LLess(Local0, \_PR.PBYT)) {
> + Store(Zero, Local1)
> + Store(DerefOf(Index(Local3, Local0)), Local2)
> + While(LLess(Local1, 8)) {
> + NTFY(Add(Multiply(Local0, 8), Local1), And(Local2, 1))
> + ShiftRight(Local2, 1, Local2)
> + Increment(Local1)
> + }
> + Increment(Local0)
> + }
> +
> + Store(Zero, Local1)
> + Store(DerefOf(Index(Local3, Local0)), Local2)
> + While(LLess(Local1, \_PR.PBIT)) {
> + NTFY(Add(Multiply(Local0, 8), Local1), And(Local2, 1))
> + ShiftRight(Local2, 1, Local2)
> + Increment(Local1)
> + }
> +
> + Return(One)
> + }
> + }
> }
> diff --git a/src/acpi.c b/src/acpi.c
> index f613b03..037da46 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -344,6 +344,9 @@ build_fadt(int bdf)
> return fadt;
> }
>
> +u32 madt_csum_addr, madt_lapic0_addr;
> +u32 max_cpus_byte, max_cpus_bit;
> +
> static void*
> build_madt(void)
> {
> @@ -360,6 +363,10 @@ build_madt(void)
> madt->local_apic_address = cpu_to_le32(BUILD_APIC_ADDR);
> madt->flags = cpu_to_le32(1);
> struct madt_processor_apic *apic = (void*)&madt[1];
> + madt_csum_addr = (u32)&madt->checksum;
> + madt_lapic0_addr = (u32)apic;
The memory MADT resides in will be used from AML code and should be
marked in e820 map as ACPI NVS since ACPI data area can be reused by the
OS after it reads ACPI table.
> + max_cpus_byte = MaxCountCPUs / 8;
> + max_cpus_bit = MaxCountCPUs % 8;
> int i;
> for (i=0; i<MaxCountCPUs; i++) {
> apic->type = APIC_PROCESSOR;
> diff --git a/src/biosvar.h b/src/biosvar.h
> index b6e061b..57dd86b 100644
> --- a/src/biosvar.h
> +++ b/src/biosvar.h
> @@ -11,6 +11,20 @@
> #include "config.h" // CONFIG_*
> #include "disk.h" // struct chs_s
>
> +/* *****************************************************************
> + * use bios_info to enable dsdt get run-time madt and cpu info,
> + * and to avoid more hardcode magic number.
> + *******************************************************************/
> +#define BIOS_INFO_PHYSICAL_ADDRESS 0x000EA000
How this number is chosen? How do you now the memory is free for use?
And it should be marked as ACPI NVS in e820 as well.
> +struct bios_info {
> + u32 madt_csum_addr; /* address of MADT checksum */
> + u32 madt_lapic0_addr; /* address of first MADT LAPIC struct */
> + u32 max_cpus_byte; /* max cpus bitmap bytes */
> + u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
> +};
> +
> +extern u32 madt_csum_addr, madt_lapic0_addr;
> +extern u32 max_cpus_byte, max_cpus_bit;
>
> /****************************************************************
> * Interupt vector table
> diff --git a/src/post.c b/src/post.c
> index fb3b37f..8e30a57 100644
> --- a/src/post.c
> +++ b/src/post.c
> @@ -161,6 +161,18 @@ init_bios_tables(void)
> acpi_bios_init();
> }
>
> +static void init_bios_info(void)
> +{
> + struct bios_info *bios_info;
> +
> + bios_info = (struct bios_info *)BIOS_INFO_PHYSICAL_ADDRESS;
> + memset(bios_info, 0, sizeof(*bios_info));
> + bios_info->madt_csum_addr = madt_csum_addr;
> + bios_info->madt_lapic0_addr = madt_lapic0_addr;
> + bios_info->max_cpus_byte = max_cpus_byte;
> + bios_info->max_cpus_bit = max_cpus_bit;
> +}
> +
> // Main setup code.
> static void
> post(void)
> @@ -195,6 +207,7 @@ post(void)
> kbd_setup();
> mouse_setup();
> init_bios_tables();
> + init_bios_info();
>
> // Run vga option rom (if running synchronously)
> if (!CONFIG_THREADS || !CONFIG_THREAD_OPTIONROMS)
> --
> 1.6.5.6
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-21 12:44 ` Gleb Natapov
@ 2010-01-22 2:15 ` Liu, Jinsong
2010-01-22 5:45 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-22 2:15 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm@vger.kernel.org, Avi Kivity
Gleb Natapov wrote:
> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
>>> 2001
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
>> including madt bios_info and dsdt.
>>
>> 1. setup madt bios_info structure, so that static dsdt get
>> run-time madt info like checksum address, lapic address,
>> max cpu numbers, with least hardcode magic number
>> (realmode address of bios_info).
>> 2. setup vcpu add/remove dsdt infrastructure, including
>> processor related acpi objects and control methods. vcpu
>> add/remove will trigger SCI and then control method _L02.
>> By matching madt, vcpu number and add/remove action were
>> found, then by notify control method, it will notify OS
>> acpi driver.
>>
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> It looks like AML code is a port of what we had in BOCHS bios with
> minor changes. Can you detail what is changed and why for easy review
> please? And this still doesn't work with Windows I assume.
>
Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
I just change some minor points:
1. explicitly define returen value of '_MAT' as 'buffer', otherwise some linux acpi driver (i.e. linux 2.6.30) would parse error which will handle it as 'integer' not 'buffer';
2. keep correct 'checksum' of madt when vcpu add/remove, otherwise it will report 'checksum error' when using acpi tools to get madt info if we add/remove vcpu;
3. add '_EJ0' so that linux has acpi obj under /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some dsdt processor define, it will result error;
5. use 1 hardcode address bios_info structure to replace '0x514', so that it can transfer more madt info to dsdt;
Thanks,
Jinsong
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 2:15 ` Liu, Jinsong
@ 2010-01-22 5:45 ` Gleb Natapov
2010-01-22 9:08 ` Liu, Jinsong
0 siblings, 1 reply; 12+ messages in thread
From: Gleb Natapov @ 2010-01-22 5:45 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
> >>> 2001
> >> From: Liu, Jinsong <jinsong.liu@intel.com>
> >> Date: Fri, 22 Jan 2010 03:18:46 +0800
> >> Subject: [PATCH] Setup vcpu add/remove infrastructure,
> >> including madt bios_info and dsdt.
> >>
> >> 1. setup madt bios_info structure, so that static dsdt get
> >> run-time madt info like checksum address, lapic address,
> >> max cpu numbers, with least hardcode magic number
> >> (realmode address of bios_info).
> >> 2. setup vcpu add/remove dsdt infrastructure, including
> >> processor related acpi objects and control methods. vcpu
> >> add/remove will trigger SCI and then control method _L02.
> >> By matching madt, vcpu number and add/remove action were
> >> found, then by notify control method, it will notify OS
> >> acpi driver.
> >>
> >> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> > It looks like AML code is a port of what we had in BOCHS bios with
> > minor changes. Can you detail what is changed and why for easy review
> > please? And this still doesn't work with Windows I assume.
> >
>
> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
> I just change some minor points:
> 1. explicitly define returen value of '_MAT' as 'buffer', otherwise some linux acpi driver (i.e. linux 2.6.30) would parse error which will handle it as 'integer' not 'buffer';
> 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise it will report 'checksum error' when using acpi tools to get madt info if we add/remove vcpu;
> 3. add '_EJ0' so that linux has acpi obj under /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some dsdt processor define, it will result error;
What kind of errors? Qemu should never set bit over maxcpus in PRS.
> 5. use 1 hardcode address bios_info structure to replace '0x514', so that it can transfer more madt info to dsdt;
>
> Thanks,
> Jinsong
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 5:45 ` Gleb Natapov
@ 2010-01-22 9:08 ` Liu, Jinsong
2010-01-22 10:29 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-22 9:08 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm@vger.kernel.org, Avi Kivity
Gleb Natapov wrote:
> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
>> Gleb Natapov wrote:
>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
>>>>> 2001
>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
>>>> including madt bios_info and dsdt.
>>>>
>>>> 1. setup madt bios_info structure, so that static dsdt get
>>>> run-time madt info like checksum address, lapic address,
>>>> max cpu numbers, with least hardcode magic number
>>>> (realmode address of bios_info).
>>>> 2. setup vcpu add/remove dsdt infrastructure, including
>>>> processor related acpi objects and control methods. vcpu
>>>> add/remove will trigger SCI and then control method
>>>> _L02. By matching madt, vcpu number and add/remove
>>>> action were found, then by notify control method, it
>>>> will notify OS acpi driver.
>>>>
>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>> It looks like AML code is a port of what we had in BOCHS bios with
>>> minor changes. Can you detail what is changed and why for easy
>>> review please? And this still doesn't work with Windows I assume.
>>>
>>
>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
>> I just change some minor points:
>> 1. explicitly define returen value of '_MAT' as 'buffer', otherwise
>> some linux acpi driver (i.e. linux 2.6.30) would parse error which
>> will handle it as 'integer' not 'buffer';
>> 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise
>> it will report 'checksum error' when using acpi tools to get madt
>> info if we add/remove vcpu;
>> 3. add '_EJ0' so that linux has acpi obj under
>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some
>> dsdt processor define, it will result error;
> What kind of errors? Qemu should never set bit over maxcpus in PRS.
>
suppose cmdline define vcpus=4, maxvcpus=8
in original BOCHS, will scan 15 lapic items start from lapic0 of madt, where it only has maxvcpus lapic items in madt table, hence there is risk to scan over boundary, scan to other acpi table, and result in wrong vcpu online/offline status (in my test, I meet this situation).
Because of this reason, this patch limit scan maxvcpus lapic of madt.
Thanks,
Jinsong
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 9:08 ` Liu, Jinsong
@ 2010-01-22 10:29 ` Gleb Natapov
2010-01-22 10:54 ` Liu, Jinsong
0 siblings, 1 reply; 12+ messages in thread
From: Gleb Natapov @ 2010-01-22 10:29 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> >> Gleb Natapov wrote:
> >>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17 00:00:00
> >>>>> 2001
> >>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
> >>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
> >>>> including madt bios_info and dsdt.
> >>>>
> >>>> 1. setup madt bios_info structure, so that static dsdt get
> >>>> run-time madt info like checksum address, lapic address,
> >>>> max cpu numbers, with least hardcode magic number
> >>>> (realmode address of bios_info).
> >>>> 2. setup vcpu add/remove dsdt infrastructure, including
> >>>> processor related acpi objects and control methods. vcpu
> >>>> add/remove will trigger SCI and then control method
> >>>> _L02. By matching madt, vcpu number and add/remove
> >>>> action were found, then by notify control method, it
> >>>> will notify OS acpi driver.
> >>>>
> >>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>> It looks like AML code is a port of what we had in BOCHS bios with
> >>> minor changes. Can you detail what is changed and why for easy
> >>> review please? And this still doesn't work with Windows I assume.
> >>>
> >>
> >> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
> >> I just change some minor points:
> >> 1. explicitly define returen value of '_MAT' as 'buffer', otherwise
> >> some linux acpi driver (i.e. linux 2.6.30) would parse error which
> >> will handle it as 'integer' not 'buffer';
> >> 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise
> >> it will report 'checksum error' when using acpi tools to get madt
> >> info if we add/remove vcpu;
> >> 3. add '_EJ0' so that linux has acpi obj under
> >> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
> >> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
> >> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some
> >> dsdt processor define, it will result error;
> > What kind of errors? Qemu should never set bit over maxcpus in PRS.
> >
> suppose cmdline define vcpus=4, maxvcpus=8
> in original BOCHS, will scan 15 lapic items start from lapic0 of madt, where it only has maxvcpus lapic items in madt table, hence there is risk to scan over boundary, scan to other acpi table, and result in wrong vcpu online/offline status (in my test, I meet this situation).
> Because of this reason, this patch limit scan maxvcpus lapic of madt.
>
But what if cmdline will use vcpu=64? The idea was that \_PR scope will
reside in its own ssdt and for each maxvcpus value there will be ssdt
with exactly this number of processors. Ideally ssdt will be created
dynamically like it is done now, but another solution is to create them
at bios compilation time and load correct one at runtime.
BTW seabios creates very simple ssdt with \_PR scope right now and I don't
see yous patch removes this so you end up with two conflicting \_PR
scopes.
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 10:29 ` Gleb Natapov
@ 2010-01-22 10:54 ` Liu, Jinsong
2010-01-22 11:19 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-22 10:54 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm@vger.kernel.org, Avi Kivity
Gleb Natapov wrote:
> On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
>> Gleb Natapov wrote:
>>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
>>>> Gleb Natapov wrote:
>>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
>>>>>>> 00:00:00 2001
>>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>>>>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
>>>>>> including madt bios_info and dsdt.
>>>>>>
>>>>>> 1. setup madt bios_info structure, so that static dsdt
>>>>>> get run-time madt info like checksum address, lapic
>>>>>> address, max cpu numbers, with least hardcode magic
>>>>>> number (realmode address of bios_info).
>>>>>> 2. setup vcpu add/remove dsdt infrastructure, including
>>>>>> processor related acpi objects and control methods.
>>>>>> vcpu add/remove will trigger SCI and then control
>>>>>> method _L02. By matching madt, vcpu number and
>>>>>> add/remove action were found, then by notify control
>>>>>> method, it will notify OS acpi driver.
>>>>>>
>>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>>> It looks like AML code is a port of what we had in BOCHS bios with
>>>>> minor changes. Can you detail what is changed and why for easy
>>>>> review please? And this still doesn't work with Windows I assume.
>>>>>
>>>>
>>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
>>>> I just change some minor points:
>>>> 1. explicitly define returen value of '_MAT' as 'buffer', otherwise
>>>> some linux acpi driver (i.e. linux 2.6.30) would parse error which
>>>> will handle it as 'integer' not 'buffer';
>>>> 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise
>>>> it will report 'checksum error' when using acpi tools to get madt
>>>> info if we add/remove vcpu;
>>>> 3. add '_EJ0' so that linux has acpi obj under
>>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
>>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
>>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some
>>>> dsdt processor define, it will result error;
>>> What kind of errors? Qemu should never set bit over maxcpus in PRS.
>>>
>> suppose cmdline define vcpus=4, maxvcpus=8
>> in original BOCHS, will scan 15 lapic items start from lapic0 of
>> madt, where it only has maxvcpus lapic items in madt table, hence
>> there is risk to scan over boundary, scan to other acpi table, and
>> result in wrong vcpu online/offline status (in my test, I meet this
>> situation). Because of this reason, this patch limit scan maxvcpus
>> lapic of madt.
>>
> But what if cmdline will use vcpu=64? The idea was that \_PR scope
> will reside in its own ssdt and for each maxvcpus value there will be
> ssdt with exactly this number of processors. Ideally ssdt will be
> created dynamically like it is done now, but another solution is to
> create them at bios compilation time and load correct one at runtime.
>
It's OK for vcpu=64. vcpu<maxvcpus.
if maxvcpus > processor defined in dsdt, it's OK since no risk scan (bios only support 15 processor is another story);
if processor defined in dsdt > maxvcpus, it has risk to scan over boundary.
> BTW seabios creates very simple ssdt with \_PR scope right now and I
> don't see yous patch removes this so you end up with two conflicting
> \_PR scopes.
Yes, I just notice \_PR at acpi.c.
we can move \_PR to ssdt after ssdt infrastructure was full setup.
Thanks,
Jinsong
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 10:54 ` Liu, Jinsong
@ 2010-01-22 11:19 ` Gleb Natapov
2010-01-22 14:52 ` Liu, Jinsong
0 siblings, 1 reply; 12+ messages in thread
From: Gleb Natapov @ 2010-01-22 11:19 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
> >> Gleb Natapov wrote:
> >>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> >>>> Gleb Natapov wrote:
> >>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
> >>>>>>> 00:00:00 2001
> >>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
> >>>>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
> >>>>>> including madt bios_info and dsdt.
> >>>>>>
> >>>>>> 1. setup madt bios_info structure, so that static dsdt
> >>>>>> get run-time madt info like checksum address, lapic
> >>>>>> address, max cpu numbers, with least hardcode magic
> >>>>>> number (realmode address of bios_info).
> >>>>>> 2. setup vcpu add/remove dsdt infrastructure, including
> >>>>>> processor related acpi objects and control methods.
> >>>>>> vcpu add/remove will trigger SCI and then control
> >>>>>> method _L02. By matching madt, vcpu number and
> >>>>>> add/remove action were found, then by notify control
> >>>>>> method, it will notify OS acpi driver.
> >>>>>>
> >>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>> It looks like AML code is a port of what we had in BOCHS bios with
> >>>>> minor changes. Can you detail what is changed and why for easy
> >>>>> review please? And this still doesn't work with Windows I assume.
> >>>>>
> >>>>
> >>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
> >>>> I just change some minor points:
> >>>> 1. explicitly define returen value of '_MAT' as 'buffer', otherwise
> >>>> some linux acpi driver (i.e. linux 2.6.30) would parse error which
> >>>> will handle it as 'integer' not 'buffer';
> >>>> 2. keep correct 'checksum' of madt when vcpu add/remove, otherwise
> >>>> it will report 'checksum error' when using acpi tools to get madt
> >>>> info if we add/remove vcpu;
> >>>> 3. add '_EJ0' so that linux has acpi obj under
> >>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
> >>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
> >>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under some
> >>>> dsdt processor define, it will result error;
> >>> What kind of errors? Qemu should never set bit over maxcpus in PRS.
> >>>
> >> suppose cmdline define vcpus=4, maxvcpus=8
> >> in original BOCHS, will scan 15 lapic items start from lapic0 of
> >> madt, where it only has maxvcpus lapic items in madt table, hence
> >> there is risk to scan over boundary, scan to other acpi table, and
> >> result in wrong vcpu online/offline status (in my test, I meet this
> >> situation). Because of this reason, this patch limit scan maxvcpus
> >> lapic of madt.
> >>
> > But what if cmdline will use vcpu=64? The idea was that \_PR scope
> > will reside in its own ssdt and for each maxvcpus value there will be
> > ssdt with exactly this number of processors. Ideally ssdt will be
> > created dynamically like it is done now, but another solution is to
> > create them at bios compilation time and load correct one at runtime.
> >
>
> It's OK for vcpu=64. vcpu<maxvcpus.
> if maxvcpus > processor defined in dsdt, it's OK since no risk scan (bios only support 15 processor is another story);
> if processor defined in dsdt > maxvcpus, it has risk to scan over boundary.
>
>
Yes, correct. So why not export maxcpus to DSDT and at the beginning of
NTFY check that Arg0 < maxcpus then?
> > BTW seabios creates very simple ssdt with \_PR scope right now and I
> > don't see yous patch removes this so you end up with two conflicting
> > \_PR scopes.
>
> Yes, I just notice \_PR at acpi.c.
> we can move \_PR to ssdt after ssdt infrastructure was full setup.
>
> Thanks,
> Jinsong
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 11:19 ` Gleb Natapov
@ 2010-01-22 14:52 ` Liu, Jinsong
2010-01-22 15:25 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-22 14:52 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm@vger.kernel.org, Avi Kivity
Gleb Natapov wrote:
> On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
>> Gleb Natapov wrote:
>>> On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
>>>> Gleb Natapov wrote:
>>>>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
>>>>>> Gleb Natapov wrote:
>>>>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>>>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
>>>>>>>>> 00:00:00 2001
>>>>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>>>>>>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
>>>>>>>> including madt bios_info and dsdt.
>>>>>>>>
>>>>>>>> 1. setup madt bios_info structure, so that static dsdt
>>>>>>>> get run-time madt info like checksum address, lapic
>>>>>>>> address, max cpu numbers, with least hardcode magic
>>>>>>>> number (realmode address of bios_info).
>>>>>>>> 2. setup vcpu add/remove dsdt infrastructure, including
>>>>>>>> processor related acpi objects and control methods.
>>>>>>>> vcpu add/remove will trigger SCI and then control
>>>>>>>> method _L02. By matching madt, vcpu number and
>>>>>>>> add/remove action were found, then by notify control
>>>>>>>> method, it will notify OS acpi driver.
>>>>>>>>
>>>>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>>>>> It looks like AML code is a port of what we had in BOCHS bios
>>>>>>> with minor changes. Can you detail what is changed and why for
>>>>>>> easy review please? And this still doesn't work with Windows I
>>>>>>> assume.
>>>>>>>
>>>>>>
>>>>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
>>>>>> I just change some minor points:
>>>>>> 1. explicitly define returen value of '_MAT' as 'buffer',
>>>>>> otherwise some linux acpi driver (i.e. linux 2.6.30) would parse
>>>>>> error which will handle it as 'integer' not 'buffer';
>>>>>> 2. keep correct 'checksum' of madt when vcpu add/remove,
>>>>>> otherwise it will report 'checksum error' when using acpi tools
>>>>>> to get madt info if we add/remove vcpu;
>>>>>> 3. add '_EJ0' so that linux has acpi obj under
>>>>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
>>>>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
>>>>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
>>>>>> some dsdt processor define, it will result error;
>>>>> What kind of errors? Qemu should never set bit over maxcpus in
>>>>> PRS.
>>>>>
>>>> suppose cmdline define vcpus=4, maxvcpus=8
>>>> in original BOCHS, will scan 15 lapic items start from lapic0 of
>>>> madt, where it only has maxvcpus lapic items in madt table, hence
>>>> there is risk to scan over boundary, scan to other acpi table, and
>>>> result in wrong vcpu online/offline status (in my test, I meet this
>>>> situation). Because of this reason, this patch limit scan maxvcpus
>>>> lapic of madt.
>>>>
>>> But what if cmdline will use vcpu=64? The idea was that \_PR scope
>>> will reside in its own ssdt and for each maxvcpus value there will
>>> be ssdt with exactly this number of processors. Ideally ssdt will be
>>> created dynamically like it is done now, but another solution is to
>>> create them at bios compilation time and load correct one at
>>> runtime.
>>>
>>
>> It's OK for vcpu=64. vcpu<maxvcpus.
>> if maxvcpus > processor defined in dsdt, it's OK since no risk scan
>> (bios only support 15 processor is another story); if processor
>> defined in dsdt > maxvcpus, it has risk to scan over boundary.
>>
>>
> Yes, correct. So why not export maxcpus to DSDT and at the beginning
> of NTFY check that Arg0 < maxcpus then?
>
Yes, your solution also work.
In fact, we implicitly export maxcpus to DSDT by
struct bios_info {
...
u32 max_cpus_byte; /* max cpus bitmap bytes */
u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
};
this indicate maxvcpus.
In this way it can reduce scan loop.
However, I think it's not key issue. Both are OK.
Just different implement way.
Thanks,
Jinsong
>>> BTW seabios creates very simple ssdt with \_PR scope right now and I
>>> don't see yous patch removes this so you end up with two conflicting
>>> \_PR scopes.
>>
>> Yes, I just notice \_PR at acpi.c.
>> we can move \_PR to ssdt after ssdt infrastructure was full setup.
>>
>> Thanks,
>> Jinsong
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 14:52 ` Liu, Jinsong
@ 2010-01-22 15:25 ` Gleb Natapov
2010-01-22 15:56 ` Liu, Jinsong
0 siblings, 1 reply; 12+ messages in thread
From: Gleb Natapov @ 2010-01-22 15:25 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
> >> Gleb Natapov wrote:
> >>> On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
> >>>> Gleb Natapov wrote:
> >>>>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> >>>>>> Gleb Natapov wrote:
> >>>>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>>>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
> >>>>>>>>> 00:00:00 2001
> >>>>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
> >>>>>>>> Subject: [PATCH] Setup vcpu add/remove infrastructure,
> >>>>>>>> including madt bios_info and dsdt.
> >>>>>>>>
> >>>>>>>> 1. setup madt bios_info structure, so that static dsdt
> >>>>>>>> get run-time madt info like checksum address, lapic
> >>>>>>>> address, max cpu numbers, with least hardcode magic
> >>>>>>>> number (realmode address of bios_info).
> >>>>>>>> 2. setup vcpu add/remove dsdt infrastructure, including
> >>>>>>>> processor related acpi objects and control methods.
> >>>>>>>> vcpu add/remove will trigger SCI and then control
> >>>>>>>> method _L02. By matching madt, vcpu number and
> >>>>>>>> add/remove action were found, then by notify control
> >>>>>>>> method, it will notify OS acpi driver.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>>>> It looks like AML code is a port of what we had in BOCHS bios
> >>>>>>> with minor changes. Can you detail what is changed and why for
> >>>>>>> easy review please? And this still doesn't work with Windows I
> >>>>>>> assume.
> >>>>>>>
> >>>>>>
> >>>>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
> >>>>>> I just change some minor points:
> >>>>>> 1. explicitly define returen value of '_MAT' as 'buffer',
> >>>>>> otherwise some linux acpi driver (i.e. linux 2.6.30) would parse
> >>>>>> error which will handle it as 'integer' not 'buffer';
> >>>>>> 2. keep correct 'checksum' of madt when vcpu add/remove,
> >>>>>> otherwise it will report 'checksum error' when using acpi tools
> >>>>>> to get madt info if we add/remove vcpu;
> >>>>>> 3. add '_EJ0' so that linux has acpi obj under
> >>>>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
> >>>>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
> >>>>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
> >>>>>> some dsdt processor define, it will result error;
> >>>>> What kind of errors? Qemu should never set bit over maxcpus in
> >>>>> PRS.
> >>>>>
> >>>> suppose cmdline define vcpus=4, maxvcpus=8
> >>>> in original BOCHS, will scan 15 lapic items start from lapic0 of
> >>>> madt, where it only has maxvcpus lapic items in madt table, hence
> >>>> there is risk to scan over boundary, scan to other acpi table, and
> >>>> result in wrong vcpu online/offline status (in my test, I meet this
> >>>> situation). Because of this reason, this patch limit scan maxvcpus
> >>>> lapic of madt.
> >>>>
> >>> But what if cmdline will use vcpu=64? The idea was that \_PR scope
> >>> will reside in its own ssdt and for each maxvcpus value there will
> >>> be ssdt with exactly this number of processors. Ideally ssdt will be
> >>> created dynamically like it is done now, but another solution is to
> >>> create them at bios compilation time and load correct one at
> >>> runtime.
> >>>
> >>
> >> It's OK for vcpu=64. vcpu<maxvcpus.
> >> if maxvcpus > processor defined in dsdt, it's OK since no risk scan
> >> (bios only support 15 processor is another story); if processor
> >> defined in dsdt > maxvcpus, it has risk to scan over boundary.
> >>
> >>
> > Yes, correct. So why not export maxcpus to DSDT and at the beginning
> > of NTFY check that Arg0 < maxcpus then?
> >
>
> Yes, your solution also work.
> In fact, we implicitly export maxcpus to DSDT by
> struct bios_info {
> ...
> u32 max_cpus_byte; /* max cpus bitmap bytes */
> u32 max_cpus_bit; /* max cpus bitmap bits of last byte */
> };
> this indicate maxvcpus.
> In this way it can reduce scan loop.
>
Actually your scan loop is twice as big as it was in BOCHS because of
this tricks with bytes and bits.
> However, I think it's not key issue. Both are OK.
> Just different implement way.
>
The AML code is hard to read as it is, so making it simpler is
important. But the way I want to see this solved in seabios is to create
exactly maxvcpu processors in _PR scope. This will solve MS SVVP problem
too (BOCHS doesn't pass SVVP).
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 15:25 ` Gleb Natapov
@ 2010-01-22 15:56 ` Liu, Jinsong
2010-01-22 16:02 ` Gleb Natapov
0 siblings, 1 reply; 12+ messages in thread
From: Liu, Jinsong @ 2010-01-22 15:56 UTC (permalink / raw)
To: Gleb Natapov; +Cc: kvm@vger.kernel.org, Avi Kivity
Gleb Natapov wrote:
> On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
>> Gleb Natapov wrote:
>>> On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
>>>> Gleb Natapov wrote:
>>>>> On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
>>>>>> Gleb Natapov wrote:
>>>>>>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
>>>>>>>> Gleb Natapov wrote:
>>>>>>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
>>>>>>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
>>>>>>>>>>> 00:00:00 2001
>>>>>>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>>>>>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
>>>>>>>>>> Subject: [PATCH] Setup vcpu add/remove
>>>>>>>>>> infrastructure, including madt bios_info and dsdt.
>>>>>>>>>>
>>>>>>>>>> 1. setup madt bios_info structure, so that static
>>>>>>>>>> dsdt get run-time madt info like checksum
>>>>>>>>>> address, lapic address, max cpu numbers, with
>>>>>>>>>> least hardcode magic number (realmode address of
>>>>>>>>>> bios_info).
>>>>>>>>>> 2. setup vcpu add/remove dsdt infrastructure,
>>>>>>>>>> including processor related acpi objects and
>>>>>>>>>> control methods. vcpu add/remove will trigger SCI
>>>>>>>>>> and then control method _L02. By matching madt,
>>>>>>>>>> vcpu number and add/remove action were found,
>>>>>>>>>> then by notify control
>>>>>>>>>> method, it will notify OS acpi driver.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>>>>>>> It looks like AML code is a port of what we had in BOCHS bios
>>>>>>>>> with minor changes. Can you detail what is changed and why for
>>>>>>>>> easy review please? And this still doesn't work with Windows
>>>>>>>>> I assume.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
>>>>>>>> I just change some minor points:
>>>>>>>> 1. explicitly define returen value of '_MAT' as 'buffer',
>>>>>>>> otherwise some linux acpi driver (i.e. linux 2.6.30) would
>>>>>>>> parse error which will handle it as 'integer' not 'buffer';
>>>>>>>> 2. keep correct 'checksum' of madt when vcpu add/remove,
>>>>>>>> otherwise it will report 'checksum error' when using acpi tools
>>>>>>>> to get madt info if we add/remove vcpu;
>>>>>>>> 3. add '_EJ0' so that linux has acpi obj under
>>>>>>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
>>>>>>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
>>>>>>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
>>>>>>>> some dsdt processor define, it will result error;
>>>>>>> What kind of errors? Qemu should never set bit over maxcpus in
>>>>>>> PRS.
>>>>>>>
>>>>>> suppose cmdline define vcpus=4, maxvcpus=8
>>>>>> in original BOCHS, will scan 15 lapic items start from lapic0 of
>>>>>> madt, where it only has maxvcpus lapic items in madt table, hence
>>>>>> there is risk to scan over boundary, scan to other acpi table,
>>>>>> and result in wrong vcpu online/offline status (in my test, I
>>>>>> meet this situation). Because of this reason, this patch limit
>>>>>> scan maxvcpus lapic of madt.
>>>>>>
>>>>> But what if cmdline will use vcpu=64? The idea was that \_PR scope
>>>>> will reside in its own ssdt and for each maxvcpus value there will
>>>>> be ssdt with exactly this number of processors. Ideally ssdt will
>>>>> be created dynamically like it is done now, but another solution
>>>>> is to create them at bios compilation time and load correct one
>>>>> at runtime.
>>>>>
>>>>
>>>> It's OK for vcpu=64. vcpu<maxvcpus.
>>>> if maxvcpus > processor defined in dsdt, it's OK since no risk scan
>>>> (bios only support 15 processor is another story); if processor
>>>> defined in dsdt > maxvcpus, it has risk to scan over boundary.
>>>>
>>>>
>>> Yes, correct. So why not export maxcpus to DSDT and at the beginning
>>> of NTFY check that Arg0 < maxcpus then?
>>>
>>
>> Yes, your solution also work.
>> In fact, we implicitly export maxcpus to DSDT by
>> struct bios_info {
>> ...
>> u32 max_cpus_byte; /* max cpus bitmap bytes */
>> u32 max_cpus_bit; /* max cpus bitmap bits of last byte */ };
>> this indicate maxvcpus.
>> In this way it can reduce scan loop.
>>
> Actually your scan loop is twice as big as it was in BOCHS because of
> this tricks with bytes and bits.
>
No,
original BOCHS solution: PRSC has 256 loop, and NTFY has 15 scan;
this patch solution: PRSC has maxvcpus loop, and NTFY has min(15, maxvcpus) scan.
>> However, I think it's not key issue. Both are OK.
>> Just different implement way.
>>
> The AML code is hard to read as it is, so making it simpler is
> important. But the way I want to see this solved in seabios is to
> create exactly maxvcpu processors in _PR scope. This will solve MS
> SVVP problem too (BOCHS doesn't pass SVVP).
Yes, to create exactly maxvcpu processor is key points.
Thanks,
Jinsong
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt.
2010-01-22 15:56 ` Liu, Jinsong
@ 2010-01-22 16:02 ` Gleb Natapov
0 siblings, 0 replies; 12+ messages in thread
From: Gleb Natapov @ 2010-01-22 16:02 UTC (permalink / raw)
To: Liu, Jinsong; +Cc: kvm@vger.kernel.org, Avi Kivity
On Fri, Jan 22, 2010 at 11:56:44PM +0800, Liu, Jinsong wrote:
> Gleb Natapov wrote:
> > On Fri, Jan 22, 2010 at 10:52:29PM +0800, Liu, Jinsong wrote:
> >> Gleb Natapov wrote:
> >>> On Fri, Jan 22, 2010 at 06:54:42PM +0800, Liu, Jinsong wrote:
> >>>> Gleb Natapov wrote:
> >>>>> On Fri, Jan 22, 2010 at 05:08:32PM +0800, Liu, Jinsong wrote:
> >>>>>> Gleb Natapov wrote:
> >>>>>>> On Fri, Jan 22, 2010 at 10:15:44AM +0800, Liu, Jinsong wrote:
> >>>>>>>> Gleb Natapov wrote:
> >>>>>>>>> On Thu, Jan 21, 2010 at 07:48:23PM +0800, Liu, Jinsong wrote:
> >>>>>>>>>>> From cb997030cba02e7e74a29b3d942aeba9808ed293 Mon Sep 17
> >>>>>>>>>>> 00:00:00 2001
> >>>>>>>>>> From: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>>>>>>> Date: Fri, 22 Jan 2010 03:18:46 +0800
> >>>>>>>>>> Subject: [PATCH] Setup vcpu add/remove
> >>>>>>>>>> infrastructure, including madt bios_info and dsdt.
> >>>>>>>>>>
> >>>>>>>>>> 1. setup madt bios_info structure, so that static
> >>>>>>>>>> dsdt get run-time madt info like checksum
> >>>>>>>>>> address, lapic address, max cpu numbers, with
> >>>>>>>>>> least hardcode magic number (realmode address of
> >>>>>>>>>> bios_info).
> >>>>>>>>>> 2. setup vcpu add/remove dsdt infrastructure,
> >>>>>>>>>> including processor related acpi objects and
> >>>>>>>>>> control methods. vcpu add/remove will trigger SCI
> >>>>>>>>>> and then control method _L02. By matching madt,
> >>>>>>>>>> vcpu number and add/remove action were found,
> >>>>>>>>>> then by notify control
> >>>>>>>>>> method, it will notify OS acpi driver.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> >>>>>>>>> It looks like AML code is a port of what we had in BOCHS bios
> >>>>>>>>> with minor changes. Can you detail what is changed and why for
> >>>>>>>>> easy review please? And this still doesn't work with Windows
> >>>>>>>>> I assume.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yes, my work is based on BOCHS infrastructure, thanks BOCHS :)
> >>>>>>>> I just change some minor points:
> >>>>>>>> 1. explicitly define returen value of '_MAT' as 'buffer',
> >>>>>>>> otherwise some linux acpi driver (i.e. linux 2.6.30) would
> >>>>>>>> parse error which will handle it as 'integer' not 'buffer';
> >>>>>>>> 2. keep correct 'checksum' of madt when vcpu add/remove,
> >>>>>>>> otherwise it will report 'checksum error' when using acpi tools
> >>>>>>>> to get madt info if we add/remove vcpu;
> >>>>>>>> 3. add '_EJ0' so that linux has acpi obj under
> >>>>>>>> /sys/devices/LNXSYSTM:00, which is need for vcpu remove;
> >>>>>>>> 4. on Method(PRSC, 0), just scan 'xxx' vcpus that qemu get from
> >>>>>>>> cmdline para 'maxcpus=xxx', not all 256 vcpus, otherwise under
> >>>>>>>> some dsdt processor define, it will result error;
> >>>>>>> What kind of errors? Qemu should never set bit over maxcpus in
> >>>>>>> PRS.
> >>>>>>>
> >>>>>> suppose cmdline define vcpus=4, maxvcpus=8
> >>>>>> in original BOCHS, will scan 15 lapic items start from lapic0 of
> >>>>>> madt, where it only has maxvcpus lapic items in madt table, hence
> >>>>>> there is risk to scan over boundary, scan to other acpi table,
> >>>>>> and result in wrong vcpu online/offline status (in my test, I
> >>>>>> meet this situation). Because of this reason, this patch limit
> >>>>>> scan maxvcpus lapic of madt.
> >>>>>>
> >>>>> But what if cmdline will use vcpu=64? The idea was that \_PR scope
> >>>>> will reside in its own ssdt and for each maxvcpus value there will
> >>>>> be ssdt with exactly this number of processors. Ideally ssdt will
> >>>>> be created dynamically like it is done now, but another solution
> >>>>> is to create them at bios compilation time and load correct one
> >>>>> at runtime.
> >>>>>
> >>>>
> >>>> It's OK for vcpu=64. vcpu<maxvcpus.
> >>>> if maxvcpus > processor defined in dsdt, it's OK since no risk scan
> >>>> (bios only support 15 processor is another story); if processor
> >>>> defined in dsdt > maxvcpus, it has risk to scan over boundary.
> >>>>
> >>>>
> >>> Yes, correct. So why not export maxcpus to DSDT and at the beginning
> >>> of NTFY check that Arg0 < maxcpus then?
> >>>
> >>
> >> Yes, your solution also work.
> >> In fact, we implicitly export maxcpus to DSDT by
> >> struct bios_info {
> >> ...
> >> u32 max_cpus_byte; /* max cpus bitmap bytes */
> >> u32 max_cpus_bit; /* max cpus bitmap bits of last byte */ };
> >> this indicate maxvcpus.
> >> In this way it can reduce scan loop.
> >>
> > Actually your scan loop is twice as big as it was in BOCHS because of
> > this tricks with bytes and bits.
> >
>
> No,
> original BOCHS solution: PRSC has 256 loop, and NTFY has 15 scan;
> this patch solution: PRSC has maxvcpus loop, and NTFY has min(15, maxvcpus) scan.
>
>
I what code to be shorter and easier to read, not optimize loop that
will be executed once in a blue moon.
> >> However, I think it's not key issue. Both are OK.
> >> Just different implement way.
> >>
> > The AML code is hard to read as it is, so making it simpler is
> > important. But the way I want to see this solved in seabios is to
> > create exactly maxvcpu processors in _PR scope. This will solve MS
> > SVVP problem too (BOCHS doesn't pass SVVP).
>
> Yes, to create exactly maxvcpu processor is key points.
>
--
Gleb.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-01-22 16:02 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-21 11:48 [PATCH] Setup vcpu add/remove infrastructure, including madt bios_info and dsdt Liu, Jinsong
2010-01-21 12:44 ` Gleb Natapov
2010-01-22 2:15 ` Liu, Jinsong
2010-01-22 5:45 ` Gleb Natapov
2010-01-22 9:08 ` Liu, Jinsong
2010-01-22 10:29 ` Gleb Natapov
2010-01-22 10:54 ` Liu, Jinsong
2010-01-22 11:19 ` Gleb Natapov
2010-01-22 14:52 ` Liu, Jinsong
2010-01-22 15:25 ` Gleb Natapov
2010-01-22 15:56 ` Liu, Jinsong
2010-01-22 16:02 ` Gleb Natapov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox