Hi,
JohnWilson wrote:
A little googling tells me that PCIe has no interrupt lines whatever and it's all emulated using MSI.
That sounds like a major over-simplification to me.
For MSI, as far as PCI is concerned, it's not really any different to any other "write to the physical address space" issued by a device. The trickery is that the address being written to just happens to correspond to the local APIC/s and the local APIC interprets this write as an IRQ occurring.
For legacy PCI IRQs, there's a special "legacy IRQ that is not a write to the physical address space at all" message from the device to the PCI host; where (at least conceptually) the PCI host converts this special message into a signal on a wire that's connected to all the legacy stuff in the chipset (possibly an "IMCR" thing to disconnect/connect wires to IO APIC or PIC, an IO APIC input, a "PCI to ISA IRQ" router, ...).
It is impossible to emulate legacy IRQs (which need to be a signal on a wire connected indirectly to bunch of stuff) with MSI (which completely bypasses the IO APIC and PIC and goes directly to local APIC/s).
JohnWilson wrote:
If possible I really want to avoid embracing MSI for real, since even when I enable SMP I'm still programming the IOAPICS in virtual-wire mode so I can keep the 8259As in charge of ints.
Don't mix PIC and IO APIC.
Once upon a time (a long time ago) this was pointless but "supported in theory, sort of, for some chipsets and not others". Then ACPI was invented. ACPI only supports 2 possibilities - using PIC and not using IO APIC (default), or using IO APIC and not using PIC.
JohnWilson wrote:
(I have to do that because another build of my system runs under DOS instead of being its own OS, so there may be externals drivers/TSRs that are catching interrupts, so I have to party like it's 1981 just to be compatible with them.) So I'm hoping I just need to unmask an MSI int bit, or enable a bus bridge (this is the only thing on bus #2), or some other thing.
Your build system should be irrelevant - all it does is create and process files, possibly resulting in a small number of "final files" (e.g. maybe a single "bootable ISO image for CDs" file). It has nothing to do with what happens when the OS is running (e.g. when someone boots the "bootable CD").
I think what you mean here is that you decided to extend DOS (and use DOS at run-time and not just for a build system), to make sure that you have no hope of ever doing anything correctly due to the severe (and "undesirable for everyone involved") limitations of an OS that sadly became obsolete garbage 20 years ago (note: "sadly" because it should have became obsolete garbage over 30 years ago instead).
Cheers,
Brendan