How are you doing time-sharing in SE mode? You could probably use the _asid field to distinguish virtual addresses from different processes.
Steve On Wed, Aug 17, 2011 at 9:11 AM, Stevenson Jian <[email protected]>wrote: > Thanks, just a followup on what I am trying to do. I am trying to identify > some properties of individual instructions in regards to cache access. > However, I am doing it in a time-sharing context where the same applications > will be switch in and out of the CPU. Therefore, virtual address of the > instructions making the load/store will not suffice. Using the physical > address is one way of identifying the instructions uniquely. Is there > another way to go about doing it in M5? If not, could someone point to where > I should look to go about translating the virtual PC to physical instruction > address? I am using SE. > Thanks, > Steve > > > On Wed, Aug 17, 2011 at 10:55 AM, Stevenson Jian > <[email protected]>wrote: > >> Oh I see, _paddr and _vaddr are for instruction fetches, while _pc is for >> regular loads and stores. Can someone confirm for me whether for a packet >> accessing the cache, packet->request->getPC() returns a physical address or >> virtual address of the instruction that is making the load/store? How would >> I verify which one it is? If it returns a virtual address, how do I >> translate the virtual address to a physical address in m5? >> Thanks, >> Steve >> >> >> On Wed, Aug 17, 2011 at 12:43 AM, Steve Reinhardt <[email protected]>wrote: >> >>> For loads and stores, the pc is obviously not related to the vaddr or >>> paddr. >>> >>> For instruction fetches, you're probably best off just ignoring the pc; >>> the only reason it's there is because the same packet structure is shared >>> between fetches and loads/stores. >>> >>> Steve >>> >>> >>> On Tue, Aug 16, 2011 at 9:43 PM, Stevenson Jian <[email protected] >>> > wrote: >>> >>>> Hi, >>>> Looking at src/mem/request.hh, I see that there are the following 3 >>>> methods: getPC(), getPaddr(), and getVaddr(); The description of each are >>>> given in the following: >>>> _pc: program counter of initiating access; for tracing/debugging >>>> _paddr: The physical address of the request. >>>> _vaddr: The virtual address of the request. >>>> >>>> So what exactly is _pc? If _pc holds the virtual address to the >>>> instruction sending out the request to access the cache, then it should be >>>> equal to _vaddr. If _pc holds the physical address to the instruction >>>> sending out the request to access the cache, then it should be equal to >>>> _paddr. I am confused why there are 3 of them, pc, paddr, and vaddr, since >>>> one of them has to be a repeat... >>>> Thanks, >>>> Steve >>>> >>>> On Tue, Aug 16, 2011 at 8:14 PM, <[email protected]> wrote: >>>> >>>>> If I remember it correctly, the addresses exposed to cache modules are >>>>> all physical addresses. >>>>> >>>>> Leonard >>>>> >>>>> >>>>> >>>>> >>>>> On , Stevenson Jian <[email protected]> wrote: >>>>> > Hi,I would like to trace the physical address of the instruction that >>>>> is accessing the cache. I see that there is in the packet going from the >>>>> CPU >>>>> to the cache there is the PacketPtr->getPC() method. I assume that this is >>>>> the virtual address of the instruction reading the cache. However, what >>>>> would be the best way to go about getting the physical address of the >>>>> instruction accessing the cache? >>>>> > >>>>> > Thanks a lot of your help, >>>>> > Steve >>>>> > >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
