OSDev.org

Hi all,

I'm parsing the MPCT of hte MP Spec tables and get interesting entries:

• CPU: enabled, BSP, APIC ID = 0x01, APIC version = 0x10
• CPU: enabled, AP, APIC ID = 0x01, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• IOAPIC: address = 0xFEC00000, APIC ID = 0x01

Sure, I ignore the "disabled" CPUs. But: The APIC ID 0x01 is twice there (one for a Local APIC and the same for the IO APIC)! (Yes, I checked my printing and also did a mem dump and examined the structures by hand. So I'm sure that is what the BIOS reports.)

What do I do with this? Should I rely on the reported IDs or should I allocate IDs for each (Local, IO)-APIC myself?

Thanks!

Hi:

Did you encounter this in an emulator, or on real hardware?

This is on real HW. It's a HP Compaq dc7900, its BIOS is version 78661 (v01.16).
Qemu works just fine.

Hi,

deadbeef wrote:This is on real HW. It's a HP Compaq dc7900, its BIOS is version 78661 (v01.16).
Qemu works just fine.

For starts, try finding out what your OS thinks about the hardware. On Linux, doing something like "cat /proc/cpuinfo" might give the required information. On Windows, I'm pretty sure you could find out some similar application.

Also, posting your code to see if there's any bug in it might help.

Regards,
Shikhin

Do the acpi tables give the same results as the mp tables? Most modern oses use acpi these days to enumerate processors and apics, chances are that the bios may be buggy and its not been fixed as most users wouldn't notice the bug to report it...

Linux sees the same information, but uses ACPI tables. It reports

• LAPIC with ID 0, enabled
• LAPIC with ID 1, enabled
• LAPIC with ID 0, disabled
• LAPIC with ID 0, disabled
• IOAPIC with ID 1

And it says it's using IOAPIC for interrupt routing and seems to use the IOAPIC with ID=1 and the Local APIC with IDs 0 and 1.

Is the IOAPIC ID relevant anyhow?

Actually it's not the same information. Compare the results carefully:

deadbeef wrote:

• CPU: enabled, BSP, APIC ID = 0x01, APIC version = 0x10
• CPU: enabled, AP, APIC ID = 0x01, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• IOAPIC: address = 0xFEC00000, APIC ID = 0x01

deadbeef wrote:

• LAPIC with ID 0, enabled
• LAPIC with ID 1, enabled
• LAPIC with ID 0, disabled
• LAPIC with ID 0, disabled
• IOAPIC with ID 1

Your code reports two local APICs with ID = 0x01, while Linux shows APIC IDs 0x00 and 0x01 for the two enabled CPUs.

The IOAPIC IDs are located in a separate numbering scheme, so there is no conflict if there is some local APIC and some IOAPIC with the same ID number.

XenOS wrote:Actually it's not the same information. Compare the results carefully:

Oops, sorry. That was a typo introduced by me. The MP tables also report APIC ID 0x00 for the BSP.
So again, corrected, that is:

• My OS with MP Spec tables
• CPU: enabled, BSP, APIC ID = 0x00, APIC version = 0x10
• CPU: enabled, AP, APIC ID = 0x01, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• CPU: disabled, AP, APIC ID = 0x00, APIC version = 0x10
• IOAPIC: address = 0xFEC00000, APIC ID = 0x01

• Linux with ACPI tables
• LAPIC with ID 0, enabled
• LAPIC with ID 1, enabled
• LAPIC with ID 0, disabled
• LAPIC with ID 0, disabled
• IOAPIC with ID 1

XenOS wrote:The IOAPIC IDs are located in a separate numbering scheme, so there is no conflict if there is some local APIC and some IOAPIC with the same ID number.

Oh, interesting. I had assumed that the IDs have to be unique amongst all APICs (including both Local APICs and IO APICs). You tell me that the APIC IDs of IOAPICs have to be unique over all IOAPICs and APIC IDs of LocalAPICs have to be unique over all LocalAPICs. Correct?

Hmm... That seems odd to me. I mean in ancient times there was the dedicated APIC bus and the APIC IDs were used to address entities on that bus. So the IDs should have been unique amongst all the APICs back then. It's likely that it is not relevant anymore (maybe in modern systems the IOAPICs don't need a ID at all). But that's just me guessing.

Can someone verify/falsify this?

I'm not too sure about all this, so please take everything with a grain of salt.

deadbeef wrote:Oh, interesting. I had assumed that the IDs have to be unique amongst all APICs (including both Local APICs and IO APICs). You tell me that the APIC IDs of IOAPICs have to be unique over all IOAPICs and APIC IDs of LocalAPICs have to be unique over all LocalAPICs. Correct?

Yes - at least that's how it should be on modern systems.

Hmm... That seems odd to me. I mean in ancient times there was the dedicated APIC bus and the APIC IDs were used to address entities on that bus. So the IDs should have been unique amongst all the APICs back then. It's likely that it is not relevant anymore (maybe in modern systems the IOAPICs don't need a ID at all). But that's just me guessing.

Indeed, there used to be a single APIC bus on older systems. Newer systems have separate buses for local APICs and IOAPICs.