I have two major comments. First, you can use a DmaPort so you can transmit an receive. Second, whatever ends up happening with interrupts, I'd like us to look fixing up all of the interrupt mechanism for all ISAs while we're at it. It's already pretty disgusting. I'd like to see all ISAs send interrupts over the memory system (we can just use the intel APIC for everything with nice default values).
Nate On Fri, Sep 5, 2008 at 11:57 PM, Gabe Black <[EMAIL PROTECTED]> wrote: > I'm working on making the various interrupt controllers talk to each > other, and I'm expecting to run into a tricky situation with multiple > inheritance. First, my patch queue is on daystrom as x86-patches if you > want to look at what I'm talking about directly. There are quite a few > patches which do a lot, but you'd mostly be interested in the later ones > having apic in their names. > > Anyway, to make the PICs and APICs and interrupt sources connect to > each other nicely, I created a class called IntDev and a class called > IntPin. IntDev is intended to be a base for anything that can accept > interrupts, and IntPin is a small class exposed through python that > refers to an IntDev and has a pin number. The python version of IntDevs > have a function called pin(line) which returns an IntPin associated with > the device and recording the correct pin. When this gets to the C++ side > of things, a device triggers its interrupt by calling a function on the > IntPin which calls a function on the IntDev and passes it the > appropriate line. This makes things much cleaner in general, and I'm > pretty happy with it. > > Then I started working on the APICs and getting them to talk to each > other, and I realize the PioPort doesn't let you -send- anything, just > receive. That's what it's supposed to do, and I don't think it would be > appropriate to try to change that, although I considered suggesting > that. I thought about it more, and it occurred to me that both APICs > have both pio aspects and interrupt message aspects which could be > represented separately. The IO APIC needs to be a PioDevice because it > does the same index/window trick the CMOS and PCI configuration space > use, and the Local APIC can be a BasicPioDevice. On top of that, they > can also have a second port which handles all the interrupt messages > between them and knows how to send and receive the messages in an > appropriate way. That way I don't have to reinvent the PioPort, mess it > up trying to make it work with interrupts, or mingle the two systems. > > The next thing I thought of was that it would be handy to make this > part of the IntDev class which all (A)PICs already inherit from and > which fits this type of functionality. The PICs don't actually > communicate on the system bus, but they can ignore the interrupt port > and not attach it to anything and it would work fine. This could also > hook into the same mechanism already used to trigger interrupts through > the IntDev base class, so it could simplify things there too. > > The problem with this otherwise pretty nice setup is that by adding > a port to IntDev, I think I have to make it a MemObject. Having multiple > inheritance of an IntDev and a (Basic)PioDevice was fine since the > IntDev didn't have any other bases or weird constructors or anything > like that. If it becomes a memobject, however, then there will be a > diamond in the inheritance hierarchy through the two bases back to > MemObjects and below, and I also remember getting constructors to work > in this sort of situation was a real pain. > > It'd be a real shame not to be able to set things up this way, or to > even have to undo the IntDev/IntPin mechanism I have, so my question for > you guys is how I can get this to work. Can I get away with not making > IntDev a memobject? If not can I get the multiple inheritance to work > without causing a lot of grief somehow? > > Gabe > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
