I *should* have the fix for this posted tomorrow. I'm re-running all
the regressions now.
-Korey
On Tue, Apr 6, 2010 at 3:34 AM, Gabe Black <gbl...@eecs.umich.edu> wrote:
> Without looking into it too deeply what you're saying seems plausible.
> The "best" place for this sort of initialization in SE mode is, in my
> opinion, in the process initialization code. Conceptually it's sort of
> like the OS constructing the process context. The situation sounds
> similar to SPARC where 32 bit processes need to set a bit in a system
> register that forces translation to truncate addresses.
>
> Gabe
>
> Korey Sewell wrote:
>> Following up on this, it seems that Brad is correct about where the
>> uninitialized values originate. Specifically, this code snippet in
>> src/arch/alpha/tlb.cc is the culprit:
>>
>>> mode_type mode =
>>>
>>> (mode_type)DTB_CM_CM(tc->readMiscRegNoEffect(IPR_DTB_CM));
>>>
>>
>> That uninitialized value eventually trickles down to these conditions:
>> "if (!(entry->xwe & MODE2MASK(mode))) {"
>> and
>> "if (!(entry->xre & MODE2MASK(mode))) {"
>>
>> For SE mode, I'm wondering where/if the IPR registers are ever
>> initialized? The indexing to the IPR registers get set in
>> "initializeIprTable" but the actual registers themselves do not to my
>> knowledge . Since SE is primarily just user_mode execution, I would
>> guess typically the IPR registers dont matter for execution except for
>> a case like this where TLB faults need to acquire a IPR value.
>>
>> If I set the IPR_DTB_CM register to an arbitrary value in the ISA
>> constructor (arch/alpha/isa.cc), then the valgrind "uninitialized"
>> error goes away. However, I'm not exactly sure what that value should
>> be set to for a SE workload (i'm assuming in FS, the kernel sets that
>> appropriately), and its not exactly the cleanest solution to hardcode
>> that in the constructor even if I were sure of the right value.
>>
>> It's possible, that the uninitialized values causes the # of TLB
>> faults in SE mode to change, allowing the actual simulation output to
>> the stay the same but slightly changing the execution time and other
>> "small" stats. That's just my theory though.
>>
>> Anyone have additional thoughts on this?
>>
>>
>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
--
- Korey
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
