I was thinking about this more, and, bus frequency aside, it seems
like the LAPIC is basically exactly what that interrupts object I made
in the CPU is for, namely managing interrupts and feeding them one at a
time on request and according to the ISA's policy to the CPU. At the
moment that's just a C++ class for the purpose of abstraction if I
remember right, but it might be good to promote it to a full simobject.
That limits people's ability to put it in weird places, but they'd
probably want to do that with the IO APIC (the one the devices actually
talk to) anyway. This also touches on something I've been thinking
about, namely that control registers might be more closely associated
with particular structures like the TLB or the interrupts object or the
register flattening than with the CPU itself or controlling
instructions. I was thinking it might be a good idea to set up some sort
of call back interface on the MiscRegFile so those "devices" can keep
track of those values more with an interrupt model than a polling model
which would probably perform much better. The actual storage could be
moved over to them or not, that's more of an implementation detail, but
either way it would immediately take care of the performance problems
with SPARCs register window handling stuff.
Gabe
Steve Reinhardt wrote:
On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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. [...] 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.
Yea, that's the kind of thing I meant by "fiddling with address
mappings". I wouldn't disagree that it's a bit hackish, but it seems
plenty scalable to me. If you do that it does solve the "all the
APICs on one local bus" problem too.
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.
The tricky part here is doing that without adding latency to non-APIC
memory accesses (and appropriately forwarding flow-control state
through from the cache, etc.). It's probably doable but it would be
nicer to have a more general solution that didn't require this (IMO).
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.
Don't forget that part of the point of m5 is to be able to model
things that are "substantially unrealistic", like putting a PCI NIC
next to the L2 cache :-). I think a solution that lets you put the
APIC wherever you want is a good idea, even if most of those places
are obviously stupid.
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.
I think the key is separating the stuff that needs to be a certain way
to get things to work from the stuff that is just done a certain way
just because that's easy/traditional/whatever. So clearly the APIC
timer needs to run at a frequency within some range, such that the CPU
can figure out what that frequency is, but I'm guessing that as long
as that frequency is reasonable it doesn't matter exactly what it's
relationship is to the interconnect. So just having a parameter that
lets you set the frequency sounds fine to me; if in the longer term we
find that there really is a need to have it tied to the interconnect
frequency we can always set that up in the python.
Steve
------------------------------------------------------------------------
_______________________________________________
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
