> Date: Wed, 20 Dec 2023 08:37:32 +0100
> From: Emile 'iMil' Heitor <i...@home.imil.net>
>
> On 12/20/23 06:55, Emile 'iMil' Heitor wrote:
>
> > Well that's the thing, I can't find where does MMIO attaches on FreeBSD,
> > they have a very simple way of creating the resources:
>
> After a bit of digging, their virtio_mmio device attaches to "nexus0",
> which if I understand correctly, is our mainbus equivalent.
This is presumably some platform-specific irq numbering scheme.
I skimmed through the FreeBSD sources and it looks like, on x86:
1. irqs [0,16) are probably verbatim i8259 vectors, which you can get
at with intr_establish_xname(irq, &i8259_pic, ...)
2. irqs in [0,n), where n is the number of pins, might also be ioapic
vectors (which might overlap with i8259?)
3. mptable might determine more ioapic irq numbers allocated
consecutively after the first zero-based ioapic
4. ACPI MADT, if present, might determine more ioapic irq numbers
starting from GlobalIrqBase
5. irq numbers starting at first_msi_irq, which is one higher than all
the previously allocated irq numbers, are for MSI
It would be nice if someone laid out a map of how these interrupt
numbering schemes work and are related (and how they are numbered on
both FreeBSD and NetBSD). I'm sure I can spend hours poring through
the Intel and ACPI manuals to create the reverse map but it's a pain!
My guess is that this is not going to be MSI -- it'll either be i8259
or ioapic. In that case, it may work to do this:
struct ioapic_soft *ioapic = ioapic_find_bybase(irq);
struct pic *pic;
int pin;
if (ioapic != NULL) {
/*
* Some logic in x86/acpi/acpi_machdep.c has a
* conditional on this, but I can't see how we
* could possibly have a struct ioapic_softc
* whose sc_pic.pic_type is not PIC_IOAPIC, so
* I think that must be a dead branch.
*/
KASSERT(ioapic->sc_pic.pic_type == PIC_IOAPIC);
pic = &ioapic->sc_pic;
pin = irq - pic->pic_vecbase;
irq = -1;
} else {
pic = &i8259_pic;
pin = irq;
}
ih = intr_establish_xname(irq, pic, pin, ...);
