2012/3/8 Teng-Feng Yang <[email protected]> > 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? > > Yes thats correct. One thing to add is that all the exceptions are handled at commit stage to make sure we don't handle exception that was on not-taken path. Also 'copy_from_user' must be renamed to 'copy_from_vm'.
- Avadh > 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
