One problem is that this isn't a parent/child relationship. For
instance, there could be four CPUs and four local APICs all on the same
bus, and they need to know which one goes with which CPU. In that case
it would be arbitrary. If the interconnect isn't a bus, then you can't
just stick the APICs anywhere since they're supposed to be tightly
integrated on die. You'd need to make sure they ended up very close to
their CPUs, and having that over a network hop would be substantially
unrealistic. Also, all the local APICs appear at the same address but
are only visible to their CPU. I was going to try to deal with that by
sticking them into their own address space multiplexed on some address
bits, but I don't like the scalability of that. Another idea is a bus
local to the CPU which has the CPU and APIC on it. That would have to
connect to the external interconnect somehow. That could also be a home
for the page table walker and tlb eventually if those go "off chip" and
into the memory system. I don't think it matters much whether the CPU
can check the interconnect frequency, although it probably can through
some mechanism somewhere like CPUID or the stuff the processor sticks
into PCI config space according to the AMD kernel/BIOS developers guide.
The timer is being setup and used for something, and I would imagine
whatever is using it might break if the frequency is way off. Then again
maybe not. I'd rather make it do what it's supposed to do than to try to
figure out and fix the problems it may cause later.
Gabe
Steve Reinhardt wrote:
On Wed, May 21, 2008 at 5:44 PM, Gabe Black <[EMAIL PROTECTED]
<mailto:[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
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
