I recently added a hasPC() method to the Request object... it was just pushed to the development repo in the last week.
Steve On Sat, Feb 21, 2009 at 10:24 AM, <[email protected]> wrote: > I'm now running FS mode and seem to be getting R/W requests from the hdd, > which appear to be normal requests in every way, except they have no valid > PC/CPUid as you mention. Is there a way to determine if a request has a > valid PC without doing a lookup of the src ID (i.e. some combination of > isXXXX() methods either on the packet or request)? If one must lookup the > src ID to determine the device type and therefore PC validity, how is this > done? Thanks for your help. > > Joe > > ---- Original message ---- > >Date: Wed, 10 Dec 2008 10:12:28 +0000 > >From: Ali Saidi <[email protected]> > >Subject: Re: [m5-users] PC, TID from Packet/Request Object > >To: M5 users mailing list <[email protected]> > > > >An additional point is that read/write requests originating from a I/O > >device don't have a CPU id/PC. > > > >Ali > > > >On Dec 10, 2008, at 8:19 AM, Joe Gross wrote: > > > >> Aah, I should clarify my comments then. I tried using the > >> Request::getPC() and similar functions, but I end up with an assertion > >> error because it's not a valid PC. Presumably once a request goes from > >> being a virtual address to a physical address this is all stripped > >> away > >> (Request::setPhys()) and the assertion error happens when you try to > >> read the PC. Since I don't know until I try to read the PC. I'm able > >> to > >> read the cpu/thread ID for several requests until I get an assertion > >> error on that as well. I'm hoping to find a reliable way to be able to > >> pull these values from every request that the memory system receives. > >> > >> I'll try using those flags you mention to classify where the request > >> originated, thanks. > >> > >> Joe > >> > >> > >> Steve Reinhardt wrote: > >>> I'm a little confused by your comments... the Request object has > >>> fields for pc, _threadID, and _contextID (which is a combined > >>> cpu/thread ID, equivalent to the cpu ID for non-multithreaded cores). > >>> I believe we're pretty good about setting them when appropriate. > >>> (Some operations, like writebacks, don't have meaningful values that > >>> you can assign there.) A pointer to the same request object is > >>> generally passed around to all the Packet objects associated with the > >>> original request, so ince that information is set it should not get > >>> lost in the memory system. > >>> > >>> There is an INST_READ flag in the request too that logically ought to > >>> signal an instruction fetch, though I see that the cores generally > >>> don't set that flag. That should be easy to fix though. There's > >>> also > >>> a VPTE bit that indicates a page-table read on Alpha, though what if > >>> anything other ISAs do to distinguish page-table accesses I don't > >>> know. > >>> > >>> Steve > >>> > >>> On Tue, Dec 9, 2008 at 9:43 PM, Joe Gross <[email protected]> wrote: > >>> > >>>> Hello, > >>>> > >>>> Is it possible to somehow determine the program counter, thread ID > >>>> and/or cpu ID from a Packet or Request object? It seems that > >>>> Request was > >>>> setup to be either contain this type of data or to contain only > >>>> physical > >>>> memory location data (stripping this data before it reaches the > >>>> memory > >>>> system). This information would be very useful for a memory > >>>> controller > >>>> to implement quality of service scheduling similar to what is in > >>>> POWER5. > >>>> It would also be nice to distinguish between page table lookups, > >>>> instruction fetches and load/store ops. I see that I can > >>>> reimplement the > >>>> cache component to be able to pass along the data (or possibly > >>>> assign a > >>>> priority and send only the priority of the request), but I'm > >>>> hoping that > >>>> there's an easier way that doesn't need to change so much of M5. Any > >>>> help is appreciated. > >>>> > >>>> Joe > >>>> _______________________________________________ > >>>> m5-users mailing list > >>>> [email protected] > >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >>>> > >>>> > >>> _______________________________________________ > >>> m5-users mailing list > >>> [email protected] > >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >>> > >> _______________________________________________ > >> m5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >> > > > >_______________________________________________ > >m5-users mailing list > >[email protected] > >http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
