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
