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