ACPI AML PCI Routing

[johnsa]

Hi,

With regards to the ACPI AML tables (DSDT) should I be using the _CSR or _PRT methods to obtain the PCI IRQ routings?

[johnsa]

As a follow on question to this, how up to date / reliable are the MP tables?
I've not found a machine yet that doesn't have them but can one rely on their information in place of the ACPI ones?

[SpyderTL]

I think the MP tables are pretty reliable, considering they are pretty much mandatory for any multi-processor system to function properly. However, I don't think the MP tables include any (specific) information about multi-core systems, or hyperthreading capabilities, so you probably want to use the ACPI tables if they exist, and the MP tables if they don't.

[Brendan]

Hi,

With regards to the ACPI AML tables (DSDT) should I be using the _CSR or _PRT methods to obtain the PCI IRQ routings?

I think you'd use the _CRS (which describes the resources the device is currently using) and not the _PRT (which describes how PCI IRQs at the PCI host controller, and not PCI IRQs at the PCI device, are routed to either PIC inputs or IO APIC inputs).

However, I really don't know (I really do dislike ACPI and its AML a lot and the spec is convoluted at best).

As a follow on question to this, how up to date / reliable are the MP tables?

They're mostly deprecated now; and on some computers they either don't exist or are just dummy stubs (e.g. I have a computer with a "dual core with hyper-threading" CPU where the MP spec tables say there's only 1 CPU and give no other information).

For detecting how many CPUs and how many IO APICs, the ACPI MADT/APIC table is relatively decent; so the best approach is to use that (if ACPI exists) and only ever use the MP specification tables if there is no ACPI tables. Unfortunately this doesn't help much if you want to know how PCI devices are mapped to IO APIC inputs (unless there's no ACPI).

Also note that it's possible to devise an "PCI IRQ auto-detection" scheme that bypasses the need to use MP spec or ACPI for this. Basically, configure all the "known" IRQ sources (ISA, etc) that ACPI's MADT/APCI table tells you about; then for all other IO APIC inputs you have default IRQ handlers. When an PCI IRQ occurs one of the default IRQ handlers will be triggered, and by monitoring which devices caused an IRQ and which interrupts occured you can (eventually) figure out which devices use which interrupts.

Finally, if you can, just configure the devices to use MSI (where you tell the device which interrupt vector to use directly, and it bypasses the IO APIC inputs, etc). That skips all of the mess completely. The best part is that all modern PCI devies support MSI (it's mandatory for PCI-e).


Cheers,

Brendan

[johnsa]

I think the person / people who devised ACPI have a complete hatred of mankind and programmers in general
I don't think there can be a more convoluted method to provide system information and few basic functions to an OS.
I've managed to extract the _s5_ state, get reset and shutdown working, parsed all the tables, fadt/mcfg/madt/hpet and managed to partially decipher the _crs and _prt aml bytecode to extract the mapping values.. but that is as far as I'm prepared to go.

I like the MSI idea.. in fact I like it a lot, certainly more than probing all the devices to establish int->irq->device mapping
I wonder off hand how many of the pci devices in bochs/qemu etc support msi (or do the emulators even?) as bochs doesn't even have an mcfg table for pcie.

But as a way forward msi/msi-x is definitely an improvement!

[rdos]

I think the person / people who devised ACPI have a complete hatred of mankind and programmers in general
I don't think there can be a more convoluted method to provide system information and few basic functions to an OS.
I've managed to extract the _s5_ state, get reset and shutdown working, parsed all the tables, fadt/mcfg/madt/hpet and managed to partially decipher the _crs and _prt aml bytecode to extract the mapping values.. but that is as far as I'm prepared to go.

I think that if you decide to use ACPI, you should look at ACPICA and port it to your OS instead of creating your own. There is too much complexity in ACPI to redo it from scratch. It's bad enough that you need to fool ACPI that you are Windows in order for it to work properly.

The other method is to detect interrupts, which like Brendan says is perfectly possible to do.

I like the MSI idea.. in fact I like it a lot, certainly more than probing all the devices to establish int->irq->device mapping
I wonder off hand how many of the pci devices in bochs/qemu etc support msi (or do the emulators even?) as bochs doesn't even have an mcfg table for pcie.

But as a way forward msi/msi-x is definitely an improvement!

Yes, but you cannot rely on all devices supporting MSI (not right now at least).

As for MP-tables, these where more or less obsolete already when I started going multicore a few years ago, so no new design should depend on them. Those are only relevant if you want to support rather old hardware.