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
|
Home