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: Grzegorz Miłoś <gm281@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function
From: Abhinav Srivastava <abhinavs_iitkgp@xxxxxxxxxxx>
Date: Tue, 17 Jun 2008 22:56:04 +0530 (IST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 Jun 2008 10:26:33 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MWf5BepAWeT9f5HngRnDYR9G2Or/Stq1TrH91cM1xzGms1LIqXz2BUrh6bg6/igb7uhrLzbqAtDS4xToCQegjaPZnbJ7acbKjAy9Qyas6T4/pDoay4tJSrKpa1TJasIPl16HCjnL8Yo13Ovlr4cftI/Ni7ZiycH7449r1g4BZnY=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C47D2500.19F78%keir.fraser@xxxxxxxxxxxxx>
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>
Reply-to: abhinavs_iitkgp@xxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
 
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

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