Re: [Xen-devel] Query regarding x86_emulate_memop() function

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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