[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Query regarding x86_emulate_memop() function
Hi Keir, Thanks for the pointer. However, I am using Xen 3.2.1 version, which is kind of latest (one version lower to Xen 3.3) and I do not see emulate.c there. There is only one emulate.c which is inside hvm/svm (AMD specific). I saw emulate.c when i took the latest from xen-unstable tree from http://xenbits.xen.org Thanks for your help. Regards, Abhinav --- On Tue, 17/6/08, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote: > From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx> > Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function > To: abhinavs_iitkgp@xxxxxxxxxxx, "Grzegorz MiÅoÅ " <gm281@xxxxxxxxx> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Date: Tuesday, 17 June, 2008, 12:53 PM > See xen/arch/x86/hvm/emulate.c > > If you don;t have that file then your version of Xen is too > old. Pull the > http://xenbits.xensource.com/xen-unstable.hg repository. > > -- Keir > > On 17/6/08 07:02, "Abhinav Srivastava" > <abhinavs_iitkgp@xxxxxxxxxxx> wrote: > > > > > Hi Grzegorz, > > > > Thanks for the reply and clearing up the things. > However, I have some > > questions and please correct me if my understanding is > wrong: > > > > I looked at the hvm_emulate_write -> > sh_x86_emulate_write code and it seems to > > me that this function only emulates pagetable writes > not in general memory > > writes. Same is true for hvm_emulate_cmpxchg -> > sh_x86_emulate_cmpxchg and > > hvm_emulate_cmpxchg8b -> sh_x86_emulate_cmpxchg8b. > These are the functions > > that are eventually invoked by x86_emulate(). Only > hvm_emulate_read and > > hvm_emulate_insn_fetch functions can be used for all > purposes i.e. any memory > > read and instruction fetch. > > > > Is my understanding correct? If yes then does Xen > provide generic instruction > > emulator that can be used for any memory write or > instruction? or is there any > > sample code that I can follow. > > > > If these are not provided by Xen how difficult it > would be to implement our > > own. My understanding is providing arbitrary > instruction emulation for memory > > write should not be difficult as we can easily use > hvm_copy_to_guest_virt > > function. But what about other operations such as > compare and others? > > > > Thanks, > > Abhinav > > > > > > > > > > --- On Sat, 7/6/08, Grzegorz MiÅoÅ > <gm281@xxxxxxxxx> wrote: > > > >> From: Grzegorz MiÅoÅ <gm281@xxxxxxxxx> > >> Subject: Re: [Xen-devel] Query regarding > x86_emulate_memop() function > >> To: "Abhinav Srivastava" > <abhinavs_iitkgp@xxxxxxxxxxx> > >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > >> Date: Saturday, 7 June, 2008, 1:38 AM > >>> > >>> Hi there, > >>> > >>> I have a question regarding the functionality > of > >> x86_emulate_memop (Xen 3.1) or x86_emulate (Xen > 3.2) > >> function. This function gets called from > sh_page_fault() > >> function which is invoked when Xen receives a page > fault. > >> > >> Correct. But not only from sh_page_fault, also: > >> - ptwr_do_page_fault() (in xen/arch/x86/mm.c) > >> - vmx_realmode() (in > xen/arch/x86/hvm/vmx/realmode.c, > >> indirectly > >> through realmode_emulate_one() and > hvm_emulate_one()) > >> - handle_mmio() (in xen/arch/x86/hvm/io.c, > indirectly > >> through > >> hvm_emulate_one()) > >> > >>> Since I am not clear completely about the > emulation > >> operation performed by Xen, I have following > questions with > >> a below mentioned scenario? > >>> > >>> 1) Suppose I have a memory location that I > need to > >> protect it from being written by a guest OS. Since > a page > >> table protection works at a page level, we have to > mark > >> that complete page read-only inside the shadow > page table. > >> So, whenever a guest tries to write on that page, > writes > >> are propagated to shadow page table. Due to read > only page > >> this would create a page-fault and sh_page_fault > code would > >> be invoked. In the sh_page_fault code, we can > check whether > >> on this page the memory location which is being > written > >> (using CR2 register) is protected or not. If not, > my goal > >> is to let this operation go through. And, I heard > here this > >> emulation thing comes into the picture. > >>> > >> > >> Well, sh_page_fault() _may_ be invoked when > handling a page > >> fault (if > >> the shadow page tables are interested in this > fault), but > >> the > >> top-level page fault handler is do_page_fault(). > By default > >> the page > >> fault is propagated to the guest, unless it is > "fixed > >> up" by the > >> hypervisor (because it was a result of page > shadowing, > >> writable page > >> tables writes, mmio emulation or somesuch). > >> > >>> After checking and deciding this operation > should go > >> through, i call "goto emulate" from > sh_page_fault > >> code assuming it would emulate that operation and > update the > >> eip to the next instruction. > >> > >>> > >>> Question: Is this understanding correct? > >> > >> As far as I know x86_emulate() is not a full x86 > emulator, > >> its only > >> capable of emulating certain instruction (mostly > related to > >> page table > >> writes) that the hypervisor is interested in. You > cannot > >> emulate an > >> arbitrary instruction with it. > >> The reason why emulation is used in the first > place, is > >> that the > >> hypervisor write protects certain memory areas > (e.g. guest > >> pagetables) > >> because it wants to know about any changes to > these areas > >> (e.g. in > >> order to update it's shadows). The side effect > is that > >> any instruction > >> that writes to these memory areas must be > emulated, as if > >> the extra > >> write protection wasn't there. > >> > >>> The reason why I am asking is that since page > is > >> write-protected, it means while emulating it > should again > >> fault. Then, how does this emulation work? And, > what is the > >> use of this function? In what context it should be > used and > >> in what context it is invoked from > sh_page_fault(). > >> > >> I've already explained what the emulation is > for. > >> The reason why you don't get another page > fault when > >> emulating, is > >> that the hypervisor is capable of mapping any > memory page > >> with > >> arbitrary protection. For example, if the > x86_emulate() > >> decides that > >> it's supposed to emulate a write, it will > (most likely) > >> call > >> hvm_emulate_write() -> sh_x86_emulate_write(). > This last > >> function maps > >> the correct destination memory page by invoking > >> emulate_map_dest()). > >> > >>> > >>> And, if I have to achieve above-mentioned > (scenario) > >> functionality which part of the code I should > >> lookinto/change to achieve that. > >> > >> To tell you the truth I didn't quite get what > you want > >> to do, assuming > >> that you just want to trap writes to certain > memory > >> locations you have > >> two options: > >> a) write protect first, unprotect in page fault > handler if > >> you decide > >> that the write should go ahead, then restart the > write > >> (i.e. return > >> from the page fault handler). Note that you > wouldn't > >> catch further > >> writes to this memory page, unless you write > protected it > >> again > >> b) write protect, emulate in page fault handler > (just as > >> the shadow > >> code does). It's possible though, that > you'll have > >> to extend > >> x86_emulate, as it is liable to fail for some > instructions. > >> > >> > >> Cheers > >> Gr(z)egor(z) > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@xxxxxxxxxxxxxxxxxxx > >> http://lists.xensource.com/xen-devel > > > > > > Bollywood, fun, friendship, sports and more. You > name it, we have it on > > http://in.promos.yahoo.com/groups/bestofyahoo/ > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@xxxxxxxxxxxxxxxxxxx > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |