Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/acpi

On Mon, Jul 19, 2010 at 12:39:08PM +0000, Quentin Garnier wrote:
> When the platform uses the APIC interrupt model, OSPM associates
> processors declared in the namespace with entries in the MADT.  Prior to
> ACPI 3.0, this was accomplished using the processor object's ProcessorID
> and the ACPI Processor ID fields in MADT entries.  UID fields were added
> to MADT entries in ACPI 3.0.  By expanding processor declaration using
> Device definitions, UID object values under a processor device are used to
> associate processor devices with entries in the MADT.  This removes the
> previous 256 processor declaration limit.

Yes, you are quite right. What I meant that the Processor opcode (section
18.5.93) just says that the ID should be unique.

We can of course match against cpu_info::ci_cpuid or cpu_info::ci_initapicid,
or anything that is derived from MADT, which we should always prefer. But it
does not really matter what the base is.  Nor does it matter how and where
the ACPI CPUs are attached.

We have at least the case where the MADT values are "right" (e.g. are
derived from 0) and the processor object's values are "bogus" (e.g.
enumerated from 1 by the BIOS writer). Arguably these are BIOS bugs,
but unfortunately such flaws are not uncommon.

If you have any good ideas, I am all ears. Please feel free to commit as well.
It may be enlightening to go see how for instance FreeBSD struggled with this.

- Jukka.

Home | Main Index | Thread Index | Old Index