From: Gleb Natapov [mailto:email@example.com]
Sent: Saturday, January 30, 2010 4:19 AM
To: Liu, Jinsong
Cc: Kevin O'Connor; seabios(a)seabios.org; Jiang, Yunhong
Subject: Re: [PATCH] vcpu hotplug: Setup vcpu add/remove infrastructure
On Sat, Jan 30, 2010 at 04:14:29AM +0800, Liu, Jinsong wrote:
Gleb Natapov wrote:
OK. Let me try to explain it one more time. Currently MADT table
resides in memory of type "ACPI DATA" and AML code reads and writes
this memory during CPU hot-plug. According to ACPI spec "ACPI DATA"
ares can be reused by an OS, so consider what will happen if OS puts
its data into memory area where MADT was and later gets cpu hotplug
event. Do you see the problem now?
I just hesitate ' if OS puts its data ...'.
What is not clear here? OS is
free to reuse this memory for whatever it
Gleb, I'm a bit curious of the OperationRegion(). According to ACPI spec,
"Operation regions are regions in some space that contain hardware registers for
exclusive use by ACPI control methods. In general, no hardware register (at least
byte-granular) within the operation region accessed by an ACPI control method can be
shared with any accesses from any other source, with the exception of using the Global
Lock to share a region with the firmware". From that definition, I assume OSPM should
not access the regions defined by OperationRegion (I remember an ACPI engineer told me
this long before). I try to check Linux's implementation, but the acpi code is too
complex and I didn't get the code. If that's true, then Jinsong's current
approach is still ok, since that regions are defined as operation region already
(that's the reason I thought Jinsong's patch is ok when discussed with him). Of
course, I agree that marking it as MemNVS is better.
Jinsong, I think what Gleb means is, you need setup the memory as ACPIRangeNVS in e820
table. Maybe you can check how the address range for the MADT table is identified in e820
table. If it is defined as AddressRangeACPI or AddressRangeMemory, that memory will be
re-used by OS again. Please refer to ACPI chapter "System Address Map
Interfaces" and Table "Address Range Type". (it is chapter 14 in ACPI 4.0
spec). The range is for MADT does not gurantee it will not be used by OS.
Followed is an example in one of my system. You can see the MADT table is at 0x7fb2800,
which is marked as ACPI data (in linux, AddressRangeACPI is printed as ACPI data). That
means, after boot up, OSPM can use that range for memory allocation pool.
For how to setup the memory as NVS, you can refer to src/memmap.c, maybe using add_e820().
The example table in my system:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
BIOS-e820: 000000000009e000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007e835000 (usable)
BIOS-e820: 000000007e835000 - 000000007e936000 (ACPI NVS)
BIOS-e820: 000000007e936000 - 000000007f91d000 (usable)
BIOS-e820: 000000007f91d000 - 000000007f9c4000 (ACPI NVS)
BIOS-e820: 000000007f9c4000 - 000000007fa3c000 (usable)
BIOS-e820: 000000007fa3c000 - 000000007fa8c000 (reserved)
BIOS-e820: 000000007fa8c000 - 000000007faec000 (usable)
BIOS-e820: 000000007faec000 - 000000007fb0c000 (ACPI NVS)
BIOS-e820: 000000007fb0c000 - 000000007fb1b000 (usable)
BIOS-e820: 000000007fb1b000 - 000000007fb2c000 (ACPI data)
BIOS-e820: 000000007fb2c000 - 000000007fc00000 (usable)
BIOS-e820: 00000000ffc10000 - 00000000ffc1c000 (reserved)
BIOS-e820: 0000000100000000 - 0000000480000000 (usable)
DMI 2.5 present.
dmi_save_oem_strings_devices: out of memory.
ACPI: RSDP (v002 INTEL ) @ 0x00000000000f03b0
ACPI: XSDT (v001 INTEL S5000PSL 0x00000000 INTL 0x01000013) @ 0x000000007fb2b12
ACPI: FADT (v003 INTEL S5000PSL 0x00000000 INTL 0x01000013) @ 0x000000007fb2900
ACPI: MADT (v001 INTEL S5000PSL 0x00000000 INTL 0x01000013) @ 0x000000007fb2800
Per my understanding, os will not write madt
after booting, only AML write madt
when necessary (i.e. cpu hotplug).
Your understanding is wrong. Read spec.
So is it necessary to mark madt as ACPI NVS?
ACPI VNS or reserved. The difference is that OS should save/restore ACPI NVS
memory during S4 transition. Read the spec it is all there.