[gem5-users] (no subject)

2017-10-10 Thread Muhammad Avais
Hi,
Does GEM5 follows any specific cache coherence protocol?
 If yes? then which one?
Thanks
___
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

2017-10-10 Thread Prathap Kolakkampadath
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

2017-10-10 Thread Prakhar Javre
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