On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[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
