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 <gabebl...@google.com> 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 <pfoto...@ucdavis.edu> > 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 interference? >> >> Your feedback would be appreciated! >> >> Best, >> -- >> Pouya Fotouhi >> PhD Candidate >> Department of Electrical and Computer Engineering >> University of California, Davis >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
