[m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. See /z/m5/regression/regress-2008-09-06-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Stable
What's still left to do for stable? There's the SMT regression failure. Korey or Kevin can you guys look into that so we can get this done? Is there anything else? I have stuff just waiting to get into the tree and I'm holding off for this stable release. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] interrupt messages
I agree with Ali, any message under a cache line in length should be just fine. In fact, in some networks all messages might have to be a cache line in length. Nate On Fri, Sep 5, 2008 at 9:07 AM, Ali Saidi [EMAIL PROTECTED] wrote: I don't think there should be any problem with these working. Ali On Sep 5, 2008, at 2:48 AM, Gabe Black wrote: More concretely, if you look in appendix F of the third Intel manual, it shows the formats of the messages the APICs would send each other over the special purpose APIC bus. I'm not intending to implement one since they've used the system bus instead for quite a while, but that at least shows the quantity of information going back and forth. There's also an arbitration ID which goes away when you use the system bus, so these messages can probably be simpler than what's in the appendix. I'd guess around 64 to 128 bits per message. Gabe [EMAIL PROTECTED] wrote: The accesses are supposed to be atomic, I'm pretty sure. I think they're basically just special messages passed around on the bus which I'm approximating with reads and writes. I set aside a page for those accesses because it was a convenient size and I already needed a second page for access to the local APICs configuration space, but I don't expect anywhere near that much data to actually go into these messages. It should just be a handful of bytes. What might be best would be to create some new type/command for packets that represent interrupt messages, but I initially shied away from that because it might be hard to implement properly, could make all the devices more complex since they have to handle or at least ignore those messages, and adds clutter and complexity to the way the memory system works. I'm pretty open to suggestions if there's some way to implement things that seems obviously best. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: The memory system doesn't do any segmentation. It will choke if you try and do a single access that spans cache blocks in cached memory. For uncached physical accesses, I don't know if there are any hard limits or not, but performance would get unrealistic if you tie up a bus while a full page of data traverses it. There are ports that provide readBlob/writeBlob calls, though they're really only intended for functional accesses (like program loading, syscall emulation, etc.). I don't know enough detail about the APIC accesses to comment on the atomicity issues. I'd expect that it's designed so that you just do atomic accesses. Steve On Thu, Sep 4, 2008 at 9:23 AM, Gabe Black [EMAIL PROTECTED] wrote: I'm close to the point of sending messages between APICs, and I was thinking about the semantics of how I actually want to send the message. I need to know the specifics of a few properties of the memory system in order to be sure it will work. First, if I send a bigger message, is it possible it'll be split up before getting to it's destination? Second, if it is split up, is there any guarantee of ordering? Third, is there any easy socket style mechanism to send a bunch of bytes to one location (a bunch of small, sequential writes seems fairly clunky), or would I want to write into a buffer and then somehow signal it was all in there? I've allocated a page of memory space for each APIC so they have a space to send each other messages. I suppose a fourth concern if the buffer approach is used is that multiple APICs could compete to write into the same portion of the APICs page unless it was further divided into regions for each sender. 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-de ___ 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
Re: [m5-dev] intdev
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
Re: [m5-dev] Stable
Statistics cleanup? gcc 4.2? Ali On Sep 6, 2008, at 1:25 PM, nathan binkert wrote: What's still left to do for stable? There's the SMT regression failure. Korey or Kevin can you guys look into that so we can get this done? Is there anything else? I have stuff just waiting to get into the tree and I'm holding off for this stable release. Nate ___ 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
Re: [m5-dev] intdev
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,
Re: [m5-dev] intdev
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. Yes, you want to send the interrupt now, but in the real machine there is a propagation delay and things will have to arbitrate for the system bus. Nobody has dedicated interrupt pins anymore. So, it is much more realistic to use a DmaPort. Also, as Ali said, the DMA port will only fragment if it is longer than a cache line. We can add some sort of flag to a request that says Don't Fragment that will raise an assertion if somethign wants to cause fragmentation. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
