Avi Kivity wrote:
> On 07/07/2010 07:57 AM, Kevin O'Connor wrote:
>> Hi,
>>
>> I've been playing with the cpu hotplug SSDT changes. Attached is a
>> proposal for an alternative method of adding ACPI support.
>>
>> The idea is to continue to build a dynamic SSDT based on CountCPUs
>> and MaxCountCPUs. The dynamic SSDT entries just call methods in the
>> main DSDT.
>>
>> This is completely untested. Hopefully the patch will demonstrate
>> the idea though.
>>
>> The objective is to dynamically build an SSDT that looks something
>> like:
>>
>> =========================================================== {
>> Scope (_SB) {
>> External(CPMA, MethodObj)
>> External(CPST, MethodObj)
>> External(CPEJ, MethodObj)
>> #define DefCPU(nr) \
>> Processor (CP##nr, 0x##nr, 0x0000b010, 0x06) { \
>> Name (_HID, "ACPI0007") \
>> Name (ID, 0x##nr) \
>> Method(_MAT, 0) { \
>> Return(CPMA(ID)) \
>> } \
>> Method (_STA) { \
>> Return(CPST(ID)) \
>> } \
>> Method (_EJ0, 1, NotSerialized) { \
>> Return(CPEJ(ID, Arg0)) \
>> } \ }
>> DefCPU(00)
>> DefCPU(01)
>> DefCPU(02)
>> DefCPU(03)
>> DefCPU(AA)
>> Name(CPUS, Package() {
>> CP00, CP01, CP02, CP03, CPAA,
>> })
>> Name(CPON, Package() {
>> One, One, One, Zero, Zero
>> })
>> }
>> }
>> ===========================================================
>>
>> with a dynamic number of cpus.
>>
>> The "CPUS" package stores references to the Processor objects, and
>> the "CPON" package stores the state of which cpus are active. With
>> this info, hopefully there is no need to update the MADT tables.
>>
>> Thoughts?
>>
>
> Very nice. I thought about doing this but abandoned it as
> unmaintainable. Using external functions and the ID variable,
> however, reduces the mess to tolerable proportions, and gains us a
> lot of flexibility. We can now have any combinations of sockets and
> installed cpus.
Agree, only 1 concern
will it bring debugable/ scalable issue by hardcode aml code?
Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
