On Wed, May 21, 2008 at 5:44 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
> The kernel is now getting to a point where it's trying to calibrate the > timer in the local APIC against the TSC register. In order to mimic that, > I'm going to need to create an event to fire when the timer is supposed to > go off. This is enough of an impetus to separate the local APIC into it's > own device on the bus just outside of the CPU. That means I need to solve > some issues I've been putting off, namely making sure there's exactly one > local APIC per cpu and that they know about each other. One topology is that > the local APIC acts as an intermediary between the CPU and the interconnect, > and the other is with the APIC as a peer. The latter won't work so well with > non-bus interconnects I don't think. Why do you say that? Is there some aspect to how it's addressed that makes it different from a regular memory-mapped device? (In particular, some aspect that's not easily worked around by fiddling with address mappings?) > Also, each APIC has to know what CPU it's associated with so it can return > the right ID number and to have a pointer to make it interrupt. Seems like that should be relatively easy to take care of in python with a Parent.any parameter. > Also, the APIC needs to know what the frequency is of the interconnect it's > connected to since it runs it's timer off of a divided version of that > clock. What do people think? > Is it really architecturally visible that the timer's clock is related to the interconnect clock? Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
