Hi Gabe,
Thank you for your detailed response, really appreciate it!
The interrupt controller I'm trying to implement (at least to begin with)
is a simple one, and hopefully with the information you provided I would
have a better understanding of the code (specially what needs to be
implemented, if any, in SMBios table from interrupt assignments in MP
tables).
On a separate - yet very much related - question, do you know if the
interrupt controller we setup for the IDE controller is being used at all?
Best,
On Sat, Jul 20, 2019 at 10:52 PM Gabe Black wrote:
> Hi Pouya. I'm travelling right now so I don't have a lot of
> time/opportunity to reply to email, but I'll give it a shot. I think the
> code you're looking at is code which creates SimObjects which represent an
> in memory table that the x86 BIOS/EFI would normally set up. That is from
> the Intel MP specification which is really old and is how the OS on a
> system with multiple CPUs and a more complex interrupt scheme than ye olde
> PCs would figure out what the machine looked like. Other mechanisms like
> ACPI have superseded it, but are generally a lot more complicated and not
> as supported in gem5. I think some basic info is still in the ACPI tables
> gem5 does set up, and in the SMBIOS tables which are newer than the MP
> specification and older than ACPI, so you might need to modify those too.
> That is just telling the OS what things look like, and you will likely need
> to add something there if you add in extra interrupts.
>
> As far as how the interrupts are actually wired up, real PCI devices can
> share interrupts. I think the original PCI bus supported 4 interrupts
> called A, B, C, and D, and if you had more than 4 devices they would
> necessarily have to cooperate and share at least at the driver level. I
> forget if the hardware specification would make interrupt sharing work
> without any special attention from the devices themselves. Later types of
> PCI busses like PCI express expanded on that scheme, for instance by adding
> message based interrupts. Lets just pretend those don't exist for now.
>
> Then there is x86's interrupt architecture. There are the legacy PICs, or
> programmable interrupt controllers. Those are the IRQs 0-15 from the
> original PCs. Theses were later expanded on, including in the MP
> specification I mentioned before, to include APICs, advanced programmable
> interrupt controllers, which have had several generations. Those split
> things into an interrupt controller that lives in each core, the local
> APIC, and an APIC that lives out in the system which the devices attach to
> called the IO APIC.
>
> In gem5, the interrupt hardware is split into an interrupt controller
> which lives in each core, and then some other part that varies by
> architecture. The interrupt controller in x86 is the local APIC, and the
> "south bridge" I think has the IO APIC implemented as a device. On other
> architectures there is a platform object which more abstractly asserts or
> deasserts interrupts for a device, and that gets communicated to a CPU
> bound interrupt controller. On x86 I opted to make it work more like
> hardware with wires which can go up or down based on what the hardware is
> designed to do, and then the interrupt controller can determine what that
> means based on how it's configured. Otherwise the values in those
> configuration registers would just be ignored, and the system may not
> behave as the driver/OS wants it to. For instance, is that a level
> triggered interrupt which should keep reasserting itself? Is it edge
> triggered and should only happen once? Can it be either? It's not safe to
> try to guess ahead of time what the intention was.
>
> Interrupts in x86 are quite complicated, and setting everything up
> requires at least a basic understanding of a lot of different pieces. I
> can't possibly describe the whole thing in an email, but a lot of the
> standards and datasheets for the original chips even the fanciest newest
> CPUs pretend to have are available online. Wikipedia actually has a lot of
> good info. Fortunately, if you don't try to use the fancy stuff and just
> want a simple interrupt, you can gloss over a lot of things and get
> something to work. Good luck!
>
> Gabe
>
> On Fri, Jul 19, 2019 at 2:59 PM Pouya Fotouhi
> wrote:
>
>> Hi everyone,
>>
>> I'm trying to add a pci device, and I need to assign an interrupt line to
>> the controller I created. Looking at the setup for the ide controller
>> (configured as dev 4 on pci bus), we have "source_bus_irq = 0 + (4 << 2)"
>> and "dest_io_apic_intin = 16" in X86IntelMPIOIntAssignment.
>>
>> I tried going over the code to figure out the interrupt PIN assignments
>> (for both source and destination), but found it more complicated that I
>> thought. Can anyone comment/explain on how this setup is done? Are we
>> simply shifting the source id? Can two PCI devices share the same
>> destination PIN given there are no logical
