WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <abhinavs_iitkgp@xxxxxxxxxxx>, Grzegorz Miłoś <gm281@xxxxxxxxx>
Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 17 Jun 2008 08:23:28 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 Jun 2008 00:22:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <87017.31661.qm@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjQSwl3R92sPjw+Ed2kbwAWy6hiGQ==
Thread-topic: [Xen-devel] Query regarding x86_emulate_memop() function
User-agent: Microsoft-Entourage/11.4.0.080122
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

<Prev in Thread] Current Thread [Next in Thread>