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.
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]
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
