Hi Thanks for your reply. I recheck the Context::copy_from_user() function, and I think I might understand how the thing works to load data in fetch stage. It seems that the copy_from_user() function will first check the address with check_and_translate() function. If the tlb entry is valid, it will directly return its physical address and incur no exception. If the tlb entry is not valid, it will incur the PageRead or PageWrite exception which is handled in the following branch with cpu_x86_handle_mmu_fault(). Therefore, when the ldub_code function is called in copy_from_user(), it should never incur any exception. Am I right?
Thanks for your patience! Dennis avadh patel <[email protected]> 於 2012年3月6日上午12:21 寫道： > > 2012/3/5 Teng-Feng Yang <[email protected]> > >> Hi >> >> Thanks for this great information about ptl_stable_state, it really helps >> a lot. >> As I keep working on this problem, I have some questions and hopes >> someone could give me a hand. >> In the fetch pipeline stage, it will try to fetch and translate basic >> block via the following sequence of function calls. >> *ThreadContext::fetch() -> >> ThreadContext::fetch_or_translate_basic_block() -> >> BasicBlockCache::translate() -> TraceDecoder::fillbuf() -> >> Context::copy_from_user() * >> *-> ldub_code() -> __ldub_code() -> tlb_fill()* >> Since *tlb_fill()* is a QEMU function, the function calling to this >> function should first set ptl_stable_state. >> In fact, the calling to *tlb_fill()* in *ptl-qemu.cpp* does set >> ptl_stable_state first, and unset it after *tlb_fill()* return. >> However, the* tlb_fill()* called in* __ldub_code()* does not set >> ptl_stable_state. >> I am wondering why It seems that it pretty sure about that it will never >> generate a PF fault during the instruction fetch. >> >> tlb_fill() function doesn't always fill the tlb and returns successfully. > In case of page fault this function will not return to caller and instead > it will do a long jump and change cpu context to page fault handler. > Because of this side-effect of this function its really important that its > called only when simulator is in stable mode. So in 'copy_from_user' > function before calling ldub_code we make sure that we have a valid tlb > entry so 'tlb_fill' is not called. If you have made some changes and you'r > calling this function then make sure that a valid tlb entry is present. > Otherwise your simulation will end up in unstable mode. > > - Avadh > >> Thanks >> >> Dennis >> >> >> avadh patel <[email protected]> 於 2012年2月28日上午8:25 寫道： >> >> >>> >>> On Tue, Feb 21, 2012 at 3:59 AM, Teng-Feng Yang <[email protected]>wrote: >>> >>>> Hi >>>> >>>> I have traced the source codes of the fetch stage in PTLsim pipeline >>>> recently. >>>> As far as I know, when *Context::copy_from_user* calls ldub function, >>>> it would go to the *glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong >>>> ptr)* in *qemu/softmmu_header.h*. >>>> I have monitored that the *ptl_stable_state* will be set to 1, but I >>>> can't really find the source code which changes the value of * >>>> ptl_stable_state*. >>>> Looks like I miss something important. >>>> >>>> Any tips? >>>> >>>> 'ptl_stable_state' is used for debugging. It is used to make sure that >>> all switches to QEMU are done when simulation state is in stable mode. If >>> we return to simulation mode and 'ptl_stable_state' is 0 then it represents >>> that due to some side-effect of any code changes, marss switched to QEMU >>> while simulation state was not stable. If you'r manually calling any qemu >>> functions then this might happens because qemu uses 'long jumps' a lot and >>> because of that it might corrupt simulation state. >>> >>> 'ptl_stable_state' is set in 'ptl-qemu.cpp' file. If you are getting >>> any assertion error on this variable then check your changes and make sure >>> that you dont call any load/store function of qemu directly with invalid >>> address. You can call 'check_and_translate' function to check if address is >>> valid or not and they use qemu's load/store functions. >>> >>> - Avadh >>> >>>> Thanks >>>> >>>> Dennis >>>> >>>> _______________________________________________ >>>> http://www.marss86.org >>>> Marss86-Devel mailing list >>>> [email protected] >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>> >>>> >>> >> >> >> -- >> Teng Feng Yang >> Research Assistant of Director. P.C. Yew >> Parallel Processing Laboratory >> Institute of Information Science >> Academia Sinica, Taiwan >> Tel: 886-2-27883799#1676 >> E-mail:[email protected] >> > > -- Teng Feng Yang Research Assistant of Director. P.C. Yew Parallel Processing Laboratory Institute of Information Science Academia Sinica, Taiwan Tel: 886-2-27883799#1676 E-mail:[email protected]
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
