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
