Multiprocessor specification

[johnsa]

Hi all,

The MP floating table as defined by the Intel MP Spec points to an MP Config table, which seems very similar to the ACPI multiple APIC 'madt' table. Are these in fact the same? or does one take precedence over the other?

[johnsa]

It also seems like the entries in the MPConfig table are jacked under bochs/qemu.. although I don't believe that.. I must be doing something fishy

[frank]

MP tables will only give you a list of physical processors. ACPI tables can tell you about logical processors. If available you should always use the ACPI tables as the MP tables are not likely to even be correct anymore.

As to Bochs, I wouldn't try and use the MP tables, I think all of the focus has been on getting the ACPI tables as correct as possible.

[johnsa]

Ok,

So I'll ignore the mp table stuff altogether then for now..

So here is what I'm looking at doing and trying to find the most universal way of achieving it:

I'm basically creating system modules (below driver level) that sit on top of the kernel and provide the core services / structures for each type of system component..
So let's take the LAPIC..

1) the first thing I do is check to see if we have x2Apic support via cpuid:01h/ecx(21).
2) Then I need to obtain the LAPIC base address, default is 0fee00000h ... now the mp tables give you this address, but if i'm ignoring that should i get it's address from acpi (which table?) or from an MSR?
3) Hereafter this module just provides the register maps and base functions to interact with the lapic... so this is not an issue really.

Now in terms of the IO APIC.. I need to find out a) how many are there in the system, what are there base addresses, once again should this come from the madt/acpi table?
How would one determine if there is NO IO APIC in the system at all? ACPI table not having any IO apic records?

From what I can see in the acpi spec ALL of this can be obtained from MADT, what is odd though is under qemu smp I don't find a madt table, so then what should we fall back to?

In a uni-processor system, would the MADT still be present and used or does one just assume the default address for the lapic etc? and then how would you determine the presence of lapic/io-apic.. also would one get a uniprocessor system with multiple io-apics?

Lots of questions

[Hyperdrive]

Hi,

So I'll ignore the mp table stuff altogether then for now..

Well, MP tables work under Bochs/Qemu. The things reported are a bit strange (all PCI interrupts are routed to ISA interrupts) - but it works. But in general I think the newer and more complete standard is ACPI which will supersede / already supersedes the MPSpec.

2) Then I need to obtain the LAPIC base address, default is 0fee00000h ... now the mp tables give you this address, but if i'm ignoring that should i get it's address from acpi (which table?) or from an MSR?

Yes. ACPI's MADT has that information for you: the first field, right after the table header, is the "Local APIC Address". It's an 32 bit address. There may be "Local APIC Address Override Structures" in the MADT that provide 64 bit addresses. (See subsections 5.2.11.4 and 5.2.11.11 in the ACPI 3.0b spec).

Now in terms of the IO APIC.. I need to find out a) how many are there in the system, what are there base addresses, once again should this come from the madt/acpi table?

Yes.

How would one determine if there is NO IO APIC in the system at all? ACPI table not having any IO apic records?

Right.

From what I can see in the acpi spec ALL of this can be obtained from MADT, what is odd though is under qemu smp I don't find a madt table, so then what should we fall back to?

You can fall back to MP tables. If there are no MP tables you can fall back to manual configuration. If there is no manual configuration you can fall back to "guessing". If there is no "guessing", you can fall back to uniprocessor operation. Or, alternatively, you can refuse to boot (but I think that is a bit radical to refuse booting if you don't find multiprocessor information).

In a uni-processor system, would the MADT still be present and used or does one just assume the default address for the lapic etc? and then how would you determine the presence of lapic/io-apic.. also would one get a uniprocessor system with multiple io-apics?

First of all - IMO, "assuming" is nearly always bad.

Second - even in an uniprocessor system there may be Local and I/O APICs. "Uniprocessor" only tells you that there is only one processor. It says nothing about the environment. Well, at least Qemu doesn't generae MP tables if It's emulating only one processor. And because Qemu uses the same BIOS as Bochs (?), you will probably observe the same behaviour in Bochs. I never saw such a behaviour on real hardware, but generally it could be possible that such BIOSes are existing. In that case I would not "guess"/"assume" standard Local APIC und I/O APIC addresses but fall back to uniprocessor operation and using the legacy PIC.

--TS

[johnsa]

Ok so the plan is as follows:

Locate MADT/ACPI.. use this information to determine LAPIC address, IO APIC count and base and number of logical/physical processors (although physical isn't too relevant).

If there is NO MADT, Try to locate and use the MP tables.
If the MP tables exist and point to a valid MP config, use that.. else if it's a default config (IE: 2 processors, where to get IO APIC address from then?)

If there is NO valid MP Tables assume uni-processor (surely all valid working mp systems must have one or the other...)
In this case obtain the LAPIC address from the MSR... where do we get the io apic base/count from?

[Hyperdrive]

Ok so the plan is as follows:

Locate MADT/ACPI.. use this information to determine LAPIC address, IO APIC count and base and number of logical/physical processors (although physical isn't too relevant).

Um... Presumably you mean "logical isn't too relevant" ?!

If there is NO MADT, Try to locate and use the MP tables.
If the MP tables exist and point to a valid MP config, use that.. else if it's a default config (IE: 2 processors, where to get IO APIC address from then?)

From MP Spec 1.4, chapter 5:

To use a default configuration, a system must meet the following basic criteria:
1. The system supports two processors.
2. Both processors must execute the common Intel architecture instruction set.
3. The local APICs are located at base memory address 0FEE0_0000h.
4. The local APIC IDs are assigned consecutively by hardware starting from zero.
5. An I/O APIC is present at base memory address 0FEC0_0000h.
6. Either PIC Mode or Virtual Wire Mode is implemented as the power-on default interrupt
mode.

Please read the spec before asking...

If there is NO valid MP Tables assume uni-processor (surely all valid working mp systems must have one or the other...)
In this case obtain the LAPIC address from the MSR... where do we get the io apic base/count from?

Do you need the Local APIC in an uniprocessor setup?

And: If there is no BIOS information on where I/O APICs reside then you shouldn't assume there is one. But okay, you can try to detect the chipset and hope that the chipset uses its standard addresses. IMO, bad idea (TM) in this case.

--TS

[Brendan]

Hi,

Locate MADT/ACPI.. use this information to determine LAPIC address, IO APIC count and base and number of logical/physical processors (although physical isn't too relevant).

It depends on how good you want your OS to be, but (eventually, for the purpose of optimization) I'd build something to keep track of the system topology; includes which CPUs share the same L1/L2/L3 caches, which CPUs share the same core (hyper-threading), which CPUs share the same physical chip, etc.

If there is NO valid MP Tables assume uni-processor (surely all valid working mp systems must have one or the other...)
In this case obtain the LAPIC address from the MSR... where do we get the io apic base/count from?

You can get the local APIC address from the MSR in some CPUs, but it may be disabled by the BIOS (in this case some CPUs allow you to re-enable it, and some don't), and may not exist. It takes a fair amount of CPU detection code before you can do this correctly.

For the I/O APIC, if there's no ACPI tables and no MP tables then you won't be able to figure out which IRQs are connected to which I/O APIC inputs, so there's no point trying to figure out if there's an I/O APIC or not. Only extremely rare computers would have an I/O APIC without ACPI tables or MP tables though - a few ancient computers (from before MP Specification was released), and maybe a few very strange machines (that used Intel CPUs but weren't "PC compatible").

Do you need the Local APIC in an uniprocessor setup?

The local APIC has some serious advantages (even for uniprocessor) - the local APIC's timer is the most precise timer (that's capable of generating an IRQ) that you'll ever find; and without a local APIC you can't compensate for CPU speed changes caused by thermal throttling (no "thermal sensor IRQ") or do performance monitoring properly (no "performance monitoring IRQ").


Cheers,

Brendan

[Hyperdrive]

Hi,

Do you need the Local APIC in an uniprocessor setup?

The local APIC has some serious advantages (even for uniprocessor) - the local APIC's timer is the most precise timer (that's capable of generating an IRQ) that you'll ever find; and without a local APIC you can't compensate for CPU speed changes caused by thermal throttling (no "thermal sensor IRQ") or do performance monitoring properly (no "performance monitoring IRQ").

Full agreement. Personally I'm using the Local APIC's features in uniprocessor setups too.

It wasn't my intention to say "You don't need the Local APIC if there's only a single processor." It was more like "Check if you need/want the features provided; and if you don't need/want them, then you don't need the Local APIC."

--TS