[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Grzegorz MiÅoÅ <gm281@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • 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=;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

 
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.