There are two major problems with using the DmaPort. First, I'd want to send the interrupt -now- not when the DMA queuing latency, etc gets used up. Second, DmaPort will fragment a packet which, while maybe necessary in some cases, will break the atomicity requirements for the interrupt messages and might even make the parts of it get there out of order. While it may not -normally- fragment the message, if it does things will be broken. I would rather not use something where such a large portion of its functionality is either not needed or counterproductive.
Also, I agree the interrupt stuff should make it into the other ISAs. That's at least part of why I'm trying to build the parts that make sense outside of x86 into a separate object other things can use, and why I'm trying to avoid forcing a particular subclass or flavor of MemObject onto the various PICs. I don't know if the Intel APIC would work even with nice default values because the way it's configured is probably at least enough different from what other ISAs use that it wouldn't work without some sort of adapter layer in place. In that case, the APIC itself might as well be the adapter layer that implements the ISA interface on top of the underlying communication mechanism which is what I'm going for. In any case, I need to get it working for x86 first so I'll worry about putting in the necessary hooks and parameters in later revisions. But like I said, I definitely agree pushing this into other ISAs is important and that will be a consideration for how things go together. Gabe nathan binkert wrote: > 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 >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
