Thanks, Tim
It looks like the for the DTLB translation, some code is there to handle
this but not complete, for the ISAs that does hardware page table walk.
cpu/base_dyn_inst.hh
BaseDynInst<Impl>::read(Addr addr, T &data, unsigned flags)
{
...
initiateTranslation(req, sreqLow, sreqHigh, NULL, BaseTLB::Read);
if (fault == NoFault) {
effAddr = req->getVaddr();
effAddrValid = true;
fault = cpu->read(req, sreqLow, sreqHigh, data, lqIdx);
} else {
...
this->setExecuted();
}
It first initiate translation, and would call cpu->read() as long as a fault
has not been generated during the translation. This should work for the
Alpha, where TLB miss is treated as fault and handled in software by
PALcode. Alpha TLB returns a fault in case of a miss.
For the ISAs that does hardware page-table walk, the TLB-miss instruction
shout not either start a read (cpu->read()) or taken out of the instruction
window (this->setExecuted()). I think it should wait for the table walk to
finish and retry the execution of the load/store (it might be not true
depending on the implementation??)
I looked into the x86 code, and if the memory is timing, then the pagetable
walker would initiate a memory access and return without a fault - it means
the cpu->read() would be called w/o the translation finished. It is the same
case for the Arm.
Is there any plan or ongoing effort to support this wait-on-TLB-miss on the
other ISAs? or ideas about how to go about implementing it?
Thanks,
Min
On Mon, Jul 12, 2010 at 5:44 PM, Timothy M Jones <tjon...@inf.ed.ac.uk>wrote:
> Hi Min,
>
> The way that the TLB deals with a timing translation is specific to each
> ISA. I don't have much experience with anything other than Power but for
> that ISA, yes, you're correct. The timing translation is just a wrapper
> around the atomic translation. It seems from a quick check that Alpha is
> the same.
>
> If you actually wanted to have the fetch translation finish on a different
> cycle to the one it was initiated on then you would have to make some
> changes to the fetch stage to allow that. I wouldn't have thought it would
> be too difficult but might require splitting up several functions into code
> that's executed before the translation and code that's executed afterwards.
>
> Cheers
> Tim
>
>
> On 12/07/2010 18:14, Min Kyu Jeong wrote:
>
>> Hi,
>>
>> This question is regarding the changeset
>> (http://repo.m5sim.org/m5?cmd=changeset;node=a123bd350935).
>>
>> This initiates a timing translation and passes the read or write on
>> to the
>>
>> processor before waiting for it to finish
>>
>>
>> It looks like even in the event of TLB miss, TLB-walk does not delay the
>> actual execution of the loads. Am I correct?
>>
>> I was trying to find a reference for replacing the translateAtomic() in
>> the fetch stage w/ translateTIming(). It would require some mechanism to
>> stop the actual fetch until the translation is finished - which doesn't
>> seem to exist in the O3 CPU even for the data translation.
>>
>> Thanks,
>>
>> Min
>>
>>
>>
>> _______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
> --
> Timothy M. Jones
> http://homepages.inf.ed.ac.uk/tjones1
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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
