Re: [gem5-users] Fwd: Issue related to requests having no contextID
Hi Prakhar, Use masterId() instead. It return the master name which is set in the Python code. Take a look at this code: https://github.com/farzadfch/gem5-cache-partitioning/blob/master/cache-part.patch#L158 Farzad From: gem5-users on behalf of Prakhar Javre Sent: Wednesday, September 20, 2017 4:14 AM To: gem5-users@gem5.org Subject: [gem5-users] Fwd: Issue related to requests having no contextID 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
Re: [gem5-users] Fwd: Issue related to requests having no contextID
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
[gem5-users] Fwd: Issue related to requests having no contextID
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] Fwd: Issue related to requests having no contextID
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