I believe the I/O cache is normally paired with a bridge that lets things flow in the other direction. It's really just designed to handle accesses to cacheable space from devices on the I/O bus without requiring each device to have a cache. It's possible we've never had a situation before where I/O devices issue accesses to uncacheable non-memory locations on the CPU side of the I/O cache, in which case I would not be terribly surprised if that didn't quite work.
Steve On Mon, Nov 22, 2010 at 11:59 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: > The cache claims to support all addresses on the CPU side (or so says > the comments), but no addresses on the memory side. Messages going from > the IO interrupt controller get to the IO bus but then don't know where > to go since the IO cache hides the fact that the CPU interrupt > controller wants to receive messages on that address range. I also don't > know if the cache can handle messages passing through originating from > the memory side, but I didn't look into that. > > Gabe > > Ali Saidi wrote: > > Something has to maintain i/o coherency and that something looks an whole > lot like a couple line cache. Why is having a cache there any issue, they > should pass right through the cache? > > > > Ali > > > > > > > > On Nov 22, 2010, at 4:42 AM, Gabe Black wrote: > > > > > >> Hmm. It looks like this IO cache is only added when there are caches in > >> the system (a fix for some coherency something? I sort of remember that > >> discussion.) and that wouldn't propagate to the IO bus the fact that the > >> CPU's local APIC wanted to receive interrupt messages passed over the > >> memory system. I don't know the intricacies of why the IO cache was > >> necessary, or what problems passing requests back up through the cache > >> might cause, but this is a serious issue for x86 and any other ISA that > >> wants to move to a message based interrupt scheme. I suppose the > >> interrupt objects could be connected all the way out onto the IO bus > >> itself, bypassing that cache, but I'm not sure how realistic that is. > >> > >> Gabe Black wrote: > >> > >>> For anybody waiting for an x86 FS regression (yes, I know, you can > >>> all hardly wait, but don't let this spoil your Thanksgiving) I'm > getting > >>> closer to having it working, but I've discovered some issues with the > >>> mechanisms behind the --caches flag with fs.py and x86. I'm surprised I > >>> never thought to try it before. It also brings up some questions about > >>> where the table walkers should be hooked up in x86 and ARM. Currently > >>> it's after the L1, if any, but before the L2, if any, which seems wrong > >>> to me. Also caches don't seem to propagate requests upwards to the CPUs > >>> which may or may not be an issue. I'm still looking into that. > >>> > >>> 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 >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
