On Sep 6, 2008, at 4:26 PM, Gabe Black wrote: > 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. The only time the DMA port will break up the packet is if it's larger than a cache block. I can't imagine an interrupt message being that large. With MSI, interrupts don't magically get propagated. They device still has to arbitrate for the bus. Ali
> > > 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 >>> 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 >> > > _______________________________________________ > 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
