Hi, I am sorry but when I check the code in core/oooexec.cpp, the physaddr generated using ctx.check_and_translate(virtaddr) is also different from the physical address stored in the memoryRequest structure. So I may misunderstand the meaning of the physaddr. Anyway, can any of you tell me if the virtaddr and the way I used to fetch memory data correct or not? Because when I put/replace the data fetched into a data structure, I found the size of the data structure is greater than the the defined cache size.
Thanks, Yingying On Wed, Mar 14, 2012 at 7:48 PM, Yingying Tian <[email protected]> wrote: > Hi Avadh, > > Thank you for the detailed explanation. I am now can load data from RAM > but also encounter another problem. I found the physical address(tag) of > the block sometimes is different from the one generated using > 'ctx->check_and_translate(virtaddr,...)'. To better explain my problem, > hereunder is part of the code I modified: > > in cache_insert_cb() in cacheController.cpp: > ========================================== > CacheLine *line = cacheLines_->insert(queueEntry->request, oldTag); > Context *ctx = queueEntry->request->ctx; > Waddr virtaddr = (queueEntry->request->virtaddr) & ~63; // the base > address of current block > > int exception = 1; > int dump = 0; > PageFaultErrorCode tmp = NULL; > if(ctx){ > W64 paddr = ctx->check_and_translate(virtaddr, 0, false, false, > exception, dump, tmp, false); // should be the tag > if(exception == 0){ > W64 phys_tag = > (W64)cacheLines_->tagOf(queueEntry->request->get_physical_address()); > if(paddr == phys_tag){ // right here! > // print out match information > } > } > } > else{ > // print out error information > } > }//endif(ctx) > ... > ========================================== > After running this code both match and error information is printed out. I > then checked the place where I pass ctx and virtaddr in. That is in > core/ooopipe.cpp and core/oooexec.cpp. For example, in oooexec.cpp, the > request is generated using > L2074: request->init(core.coreid, threadid, pteaddr, ....) while > L2061: W64 pteaddr = thread.ctx.virt_to_pte_phys_addr(virtaddr, > tlb_walk_level); > > So I stored this 'virtaddr' as queueEntry->request->virtaddr for the > future access but encountered the problem stated above. > > Do I misunderstand the virtual address that should be used in loadvirt() > or something? Could you please help me solve this problem? I am sorry for > the mess of the code but it really confused me. Thank you for your help. > > > Thanks, > Yingying > > > On Fri, Mar 9, 2012 at 11:24 AM, avadh patel <[email protected]> wrote: > >> >> >> On Wed, Mar 7, 2012 at 12:27 PM, Yingying Tian <[email protected]> wrote: >> >>> To whom it may concern, >>> >>> Thank you for your help. I searched previous Q&A and found out: >>> >>> - Context::loadvirt - Load max 64bit data from given virtual address >>> - Context::loadphys - Load max 64bit data from given physical address >>> - Context::storemask_virt - Store max 64bit data to given virtual >>> address and it uses mask to write selected bytes >>> - Context::copy_from_user - Load instructions from given virtual address >>> (only used for instructions) >>> >>> So does it mean that I can use the physical address >>> (memoryRequest->get_physical_address() ) stored in memoryRequest to fetch >>> the real data that should be stored in each cache (eg. L2) by calling >>> loadphys(Waddr addr, bool internal, int sizeshift) in the corresponding >>> cache code? If not, can anyone tell me how to call the related function in >>> a right way? Thank you in advance. >>> >>> Do not use loadphys function. Its *not* used for loading data from VM. >> To read data you'll need virtual address and use that address follow these >> steps: >> >> 1. Check if your virtual address has valid TLB translation or not by >> calling 'check_and_translate' function and check 'exception' flag. >> 2. If it has a valid translation then use that virtual address and call >> 'loadvirt' function to read 64 bit data. >> >> - Avadh >> >>> >>> Thanks, >>> Yingying >>> >>> >>> >>> On Tue, Mar 6, 2012 at 8:04 PM, Paul Rosenfeld <[email protected]>wrote: >>> >>>> I'm hazy on the details at this point since it's been a while since >>>> I've looked at the code, but the main function you want is >>>> in ptlsim/sim/ptl-qemu.cpp: >>>> >>>> int Context::copy_from_user(void * target, Waddr source, int bytes, >>>> PageFaultErrorCode& pfec, Waddr& faultaddr, bool forexec) >>>> >>>> This function calls the low level ldub_user and ldub_kernel functions >>>> which actually go into QEMU's memory space and pull out the data. The >>>> funtion then copies the bytes to the target buffer that you provide. >>>> >>>> You can grep around the code to see an example for how to use it. One >>>> such example can be found when marss loads instructions to be executed into >>>> the trace buffer in ptlsim/x86/decode-core.cpp:1998 >>>> >>>> Hopefully that's enough information to get you started. >>>> >>>> >>>> >>>> >>>> On Tue, Mar 6, 2012 at 8:28 PM, Yingying Tian <[email protected]>wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thank you for your reply. Yes I'd like to know more about accessing >>>>> real data on Marss. It would be great if you could find the function and >>>>> related information for me. Thank you in advance. >>>>> >>>>> >>>>> Thanks, >>>>> Yingying >>>>> >>>>> >>>>> On Tue, Mar 6, 2012 at 6:43 PM, Paul Rosenfeld >>>>> <[email protected]>wrote: >>>>> >>>>>> The caches only store tag information. The ptlsim portion of the >>>>>> simulator mostly deals with timings, so the model only really needs to >>>>>> know >>>>>> if there was a cache hit or a cache miss. >>>>>> >>>>>> The data is available by calling into QEMU. There are some low level >>>>>> load functions that could be used to load the actual data given. At the >>>>>> moment I'm having trouble remembering which type of address you need (I >>>>>> believe it is host virtual) to get access to this data. If you need more >>>>>> detail I can try to find the function for you. >>>>>> >>>>>> On Tue, Mar 6, 2012 at 5:54 PM, Yingying Tian <[email protected]>wrote: >>>>>> >>>>>>> To whom it may concern, >>>>>>> >>>>>>> Is it possible to get the real data (cache block) fetched from the >>>>>>> main memory? As I know so far, each request contains core-id, physical >>>>>>> address, instruction/data type, etc. If I expect to check the content of >>>>>>> cache blocks, are there any ways to get the data information? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Yingying >>>>>>> >>>>>>> _______________________________________________ >>>>>>> http://www.marss86.org >>>>>>> Marss86-Devel mailing list >>>>>>> [email protected] >>>>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> http://www.marss86.org >>> Marss86-Devel mailing list >>> [email protected] >>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>> >>> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
