[SeaBIOS] [PATCH] KVM vcpu hotplug seabios infrastructure

Liu, Jinsong jinsong.liu at intel.com
Thu Jul 8 14:52:19 CEST 2010


Kevin O'Connor wrote:
> On Sun, Jun 27, 2010 at 01:28:52PM +0800, Liu, Jinsong wrote:
>>> Attached is updated patch:
> 
> I've been looking at this patch.
> 
> I've had a hard time understanding how the SSDT code works.  It looks
> like the OS calls the \_GPE._L02 method, which reads ioport
> 0xaf00-0xaf20, determines which processors have changed state, updates
> the madt tables, and then calls Notify(Cxx,).
> 
> Why is the madt table read/written?

For the question of changing MADT, I'm not quite sure your concern (why MADT not allowed to be changed?)

MADT is mainly for booting stage. ACPI 4.0a spec words:
1). OSPM does not expect the information provided in this table to be updated if the processor information changes during the lifespan of an OS boot. 
2). While in the sleeping state, processors are not allowed to be added, removed, nor can their APIC ID or Flags change.
Per my understanding, the word subtly indicate ACPI's idea: OSPM should not expect MADT as a static table.

I think whether to change MADT is not a right/wrong question, it's just an bios implement issue.
To support cpu hotplug, 2 methods are both OK, either
method 1). don't touch MADT, allocate a memory area to record latest cpu status, or
method 2). use MADT to record latest cpu status, while make sure MADT protected by being set as ACPI NVS to avoid os possibly re-allocation

method 1 is what you prefer, and method 2 is what bochs bios (Gleb) use and what native nhm-ex bios use.
Attached is 2 MADT tables before/after cpu hot-add, extracted from nhm-ex platform, its native bios change MADT lapic entries and checksum to support cpu hotplug.

> 
> I've also noticed this patch increases the seabios build size by 18K.
> This isn't great because it is 18K that then can't be used by option
> roms, and it brings seabios very close to its current 128K limit (124K
> when full debugging enabled).
> 
> -Kevin

Yes, but seems this problem cannot be totally avoided even building ssdt in acpi.c/build_ssdt() by c code.
Can the limitation 128K be increased?
I tested and find when cpus number bigger than 64, it will break 128K.
I guess c-code-build-ssdt will still break 128K when MaxCpus > 64.

Thanks,
Jinsong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APIC1.dsl
Type: application/octet-stream
Size: 52442 bytes
Desc: APIC1.dsl
URL: <http://www.seabios.org/pipermail/seabios/attachments/20100708/4aa8bfad/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APIC2.dsl
Type: application/octet-stream
Size: 52442 bytes
Desc: APIC2.dsl
URL: <http://www.seabios.org/pipermail/seabios/attachments/20100708/4aa8bfad/attachment-0003.obj>


More information about the SeaBIOS mailing list