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 > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
