[SeaBIOS] [PATCH] vcpu hotplug: Setup vcpu add/remove infrastructure

[Jiang, Yunhong]

>-----Original Message-----
>From: Gleb Natapov [mailto:gleb at redhat.com]
>Sent: Saturday, January 30, 2010 4:19 AM
>To: Liu, Jinsong
>Cc: Kevin O'Connor; seabios at 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
>wants.

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(). 

Thanks
Yunhong Jiang

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
0
ACPI: FADT (v003 INTEL  S5000PSL 0x00000000 INTL 0x01000013) @ 0x000000007fb2900
0
ACPI: MADT (v001 INTEL  S5000PSL 0x00000000 INTL 0x01000013) @ 0x000000007fb2800
0



>
>> 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.

>
>--
>			Gleb.