[Qemu-devel] Re: [Bochs-developers] [PATCH 1/2] create acpi cpu definitions

[Brendan Trotter]

Hi,

On Sun, Apr 19, 2009 at 7:20 AM, Sebastian Herbszt <address@hidden> wrote:
> Glauber Costa wrote:
>> This comes directly from kvm-userspace. It creates
>> the necessary infrastructure for cpu hotplug, by
>> creating _MAT and _STA entries in cpu devices,
>> and by allowing notifications to the guest to happen
>
> Is there a cpu hotplug specification? I would like to read up
> on the needed changes.

There isn't any CPU hotplug specification for 80x86.

The "Processor Local APIC" structure in ACPI's tables has an
"enabled/disabled" flag (just like some other structures in ACPI
tables). Hotplug CPUs that aren't present may not be listed at all (no
"disabled" entry), and "Processor Local APIC" entries may be disabled
for any number of other reasons (including a BIOS that uses fixed size
tables, that supports more CPUs than the motherboard). The only thing
an OS can assume about disabled "Processor Local APIC" entries is that
the OS must not attempt to use the CPU.

For a comparison, the ACPI specification does include support for
hotplug RAM. In this case (for ACPI 3.0) the "int 0x15, eax = 0xE820"
BIOS function returns entries with an enabled/disabled flag where
"disabled" entries must be ignored; and there's a completely separate
structure (the "Memory Affinity Structure") which contains information
about areas that are used for hot-plug RAM, which has it's one
enabled/disabled flag *and* a separate hotpluggable/not hotpluggable
flag. From this, it seems logical that if ACPI ever does support
hot-plug CPUs, then they'll use a separate structure or a separate
flag to indicate if a CPU is hot pluggable or not, and the existing
"enabled/disabled" flag will retain it's current (use/don't use)
meaning.

For some reason (unknown to me) some Linux developers made wild
assumptions about disabled "Processor Local APIC" entries, and now
they're inventing fictitious hardware to support their unfounded
assumptions.

Please, correct me if I'm wrong...


Cheers,

Brendan