Read requests to the memory addresses that are in the write queue and not
written yet to the memory has to be responded from the write queue. I am
not sure if this answer your question, but seems like this is what you are
observing.
Thanks,
Prathap
On Oct 10, 2017 2:17 AM, "Prakhar Javre" wrote:
> A gentle reminder for our last query. Please have a look.
> [Edit] We printed the command name of packets in writeQueue inside the
> chooseNext function.
>
>for(auto i = queue.begin(); i != queue.end() ; ++i) {
> DRAMPacket* dram_pkt = *i;
>if(!dram_pkt->pkt->req->hasContextId()){
> inform("command : %s, read: %d, addr: %lu",
> dram_pkt->pkt->cmdString(), dram_pkt->pkt->isRead(), (dram_pkt)->addr);
> }
> if (ranks[dram_pkt->rank]->isAvailable()) {
> queue.erase(i);
> queue.push_front(dram_pkt);
> found_packet = true;
> break;
> }
> }
>
> Turns out that some of the packets in write queue have isRead() true and
> their command is changed to readReq and readResp.
> Can anyone help us in understanding why this peculiar behavior is getting
> observed.
>
> Thanks
> Prakhar Jawre
> IIT Kanpur, India
> -
>
> Hi guys,
>
> We are implementing a scheme for protection against timing channel attacks
> in DRAM controllers. In that, it is required to choose request (for DRAM
> controller) from a specific core at any particular time. While checking for
> it, we found that a lot of requests are not having contextIDs. We also
> modified cache code to assign contextIDs to writeback requests, but
> apparently, even some of the read requests (and other requests also) are
> not having any contextID. Can you guys help us in figuring out from which
> place exactly are these requests coming?
>
> System config -
> 2 Cores, L1I, L1D, L2(shared), Prefetch off.
>
> Thanks,
> Prakhar Jawre
> IIT Kanpur, India
>
>
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users