I don't think a builder function that does everything I want will fit into the layout of the config stuff as is. I'm just going to augment what I've got to consider the number of CPUs.
Gabe Gabe Black wrote: > 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 > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
