Before I get rolling on this too seriously, should the builder function go within the python compiled into M5, or should it go into the post compile config files? Do we have a rule of thumb for what goes where? This seems important enough to be built in and not repeated in every user config, but it's also not a SimObject or anything like that.
Gabe Steve Reinhardt wrote: > I agree with Nate... I think deducing the logical system configuration > directly from an arbitrary M5 SimObject tree is going to be next to > impossible, given that the tree doesn't reflect the memory hierarchy > interconnection topology, and since the M5 tree could very easily > correspond to an undescribable config from the BIOS perspective. > > I wouldn't worry too much in the short term about making your system > builder flexible; is it even possible to describe a non-traditional > configuration like a mesh in the BIOS tables? I think having a basic > tool that supports a handful of straightforward configs is an > appropriate first step; people that feel the need to do more than that > can be responsible for generalizing your solution as needed. I'm sure > you've heard my spiel about spending too much time designing in > unnecessary generality up front... > > Steve > > On Tue, Apr 21, 2009 at 12:36 AM, Gabe Black <gbl...@eecs.umich.edu > <mailto:gbl...@eecs.umich.edu>> wrote: > > It seems reasonable, although I'm sure it will be easier said than > done > one you get down to the details. The challenge will be putting it > together so that it doesn't make so many assumptions that it becomes > useless outside of traditional sorts of configurations like, for > instance, meshes. I agree that trying to guess what the user really > wanted your at best going to be close most of the time. > > Gabe > > nathan binkert wrote: > > My initial reaction is that it's probably better to build some > sort of > > semi-configurable system builder function that creates a system with > > the right number of CPUs and the right topology of caches. If > you do > > try to deduce what the user had in mind, I just think you're > probably > > in for a very fragile system. Does this sort of thing seem > > reasonable? > > > > Nate > > > > > >> I reordered my patches so that I could push this, and now all > of the > >> remaining ones are dependent on or are hacks that force there > to be two > >> CPUs. In order to push these last ~5 patches, I need to know > how many > >> CPUs there are when I'm constructing the BIOS tables on the > python side > >> of things. > >> > >> First, I think it would be useful to have a mechanism that will > allow > >> enumerating a simobjects children that are also simobjects. > That way you > >> could, for instance, go through and gather up all the CPUs to count > >> them, assign an ISA level ID to them, etc. There are potential > >> complications where you might "leak" into some other system, > not be able > >> to follow certain configurations correctly, not make the jump over > >> ports, etc that might make this more complicated. There may > also be CPUs > >> you don't want to count that you'll, for instance, switch over > to later. > >> > >> Besides CPUs, these tables also tend to have information about > caches, > >> and at least on the x86 side they expect to be identified by depth. > >> There would need to be some way of identifying how far a particular > >> cache is from a particular CPU in order to label it the, for > instance, > >> L2. I think you may also need to know what CPUs are connected to a > >> particular cache so you can call it shared, etc. These sorts of > names > >> may not make sense in whatever crazy configuration somebody > sets up. > >> > >> Another issue is determining bus topology and interrupt > assignment. In > >> x86 each bus needs to be identified with a particular > technology, and > >> all interrupts need to be described as far as who generates > them, what > >> bus they originate on, and where they ultimately end up. Linux gets > >> confused when at least the interrupt information is wrong and > things get > >> lost. > >> > >> I think it's important for this to be automated as much as possible > >> because I will attest it can be tricky to get everything right. > Having a > >> system in place which automatically builds up a semi-qualitative > >> description of whatever whacky configuration people want to > throw at it > >> is going to be very challenging, though, because it might not > always be > >> clear what the right thing to do is when setting things up > manually, and > >> fixing a generated configuration may actually be harder than > building it > >> yourself. > >> > >> How this works has the potential to introduce a lot of > problems, and if > >> we get it wrong it could take a major effort to fix an entrenched > >> system. I see this primarily as an infrastructure, config sort > of issue, > >> so if Nate and Steve and whoever else does the python stuff > could please > >> start a discussion about this that would be the first step. > >> > >> Gabe > >> > >> Gabe Black wrote: > >> > >>> changeset 860df2c586a3 in /z/repo/m5 > >>> details: http://repo.m5sim.org/m5?cmd=changeset;node=860df2c586a3 > >>> description: > >>> X86: Fix the functions that manipulate large bit arrays > in the local APIC. > >>> > >>> diffstat: > >>> > >>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>> src/arch/x86/interrupts.hh | 6 +++--- > >>> > >>> diffs (26 lines): > >>> > >>> diff -r a61ac4a3591d -r 860df2c586a3 src/arch/x86/interrupts.hh > >>> --- a/src/arch/x86/interrupts.hh Sun Apr 19 13:17:35 2009 > -0700 > >>> +++ b/src/arch/x86/interrupts.hh Sun Apr 19 13:47:15 2009 > -0700 > >>> @@ -172,19 +172,19 @@ > >>> void > >>> setRegArrayBit(ApicRegIndex base, uint8_t vector) > >>> { > >>> - regs[base + (vector % 32)] |= (1 << (vector >> 5)); > >>> + regs[base + (vector / 32)] |= (1 << (vector % 32)); > >>> } > >>> > >>> void > >>> clearRegArrayBit(ApicRegIndex base, uint8_t vector) > >>> { > >>> - regs[base + (vector % 32)] &= ~(1 << (vector >> 5)); > >>> + regs[base + (vector / 32)] &= ~(1 << (vector % 32)); > >>> } > >>> > >>> bool > >>> getRegArrayBit(ApicRegIndex base, uint8_t vector) > >>> { > >>> - return bits(regs[base + (vector % 32)], vector >> 5); > >>> + return bits(regs[base + (vector / 32)], vector % 5); > >>> } > >>> > >>> void requestInterrupt(uint8_t vector, uint8_t > deliveryMode, bool level); > >>> _______________________________________________ > >>> m5-dev mailing list > >>> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > >>> http://m5sim.org/mailman/listinfo/m5-dev > >>> > >>> > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > >> > >> > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org <mailto: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 > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
