I've just been poking around in O3, and the way it's handling delayed
translation is looking pretty suspicious. The initiateAcc function

The executeStore function in lsq_unit_impl.hh is the only place
initiateAcc is called in O3. This is actually a wrapper function which
calls the initateAcc function on the staticInst inside.

    Fault store_fault = store_inst->initiateAcc();

    if (storeQueue[store_idx].size == 0) {
        DPRINTF(LSQUnit,"Fault on Store PC %s, [sn:%lli],Size = 0\n",
                store_inst->pcState(), store_inst->seqNum);

        return store_fault;
    }

    assert(store_fault == NoFault);

What I think is going on here is that O3 expects if the store queue
entry was initialized must not have caused a fault, so go ahead with
execution.

If you look for translateTiming, the only place that's called by
initiateTranslation in base_dyn_inst.hh which is called by readBytes and
writeBytes.

    if (TheISA::HasUnalignedMemAcc) {
        splitRequest(req, sreqLow, sreqHigh);
    }
    initiateTranslation(req, sreqLow, sreqHigh, NULL, BaseTLB::Read);

    if (fault == NoFault) {
        effAddr = req->getVaddr();
        effAddrValid = true;
        fault = cpu->read(req, sreqLow, sreqHigh, data, lqIdx);
    } else {

The callback used for when translation is finished is finishTranslation:

template<class Impl>
inline void
BaseDynInst<Impl>::finishTranslation(WholeTranslationState *state)
{
    fault = state->getFault();

    if (state->isUncacheable())
        isUncacheable = true;

    if (fault == NoFault) {
        physEffAddr = state->getPaddr();
        memReqFlags = state->getFlags();

        if (state->mainReq->isCondSwap()) {
            assert(state->res);
            state->mainReq->setExtraData(*state->res);
        }

    } else {
        state->deleteReqs();
    }
    delete state;
}

So if translation finishes immediately, the fault gets set in
finishTranslation iniline with the initiateTranslation call, and when
you get back to readBytes/writeByte you can check it. If not, the
translation just cleans up after itself and disappears, and the fault is
lost.

Am I interpreting this correctly? Is this broken, or am I just missing
some element that makes it work? Making this work correctly would make
implementing my initiateAcc commits change easier because then the
faults from executing initiateAcc and translation are clearly separated,
not mushed together like they are now.

Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to