[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>
  • From: Abhinav Srivastava <abhinavs_iitkgp@xxxxxxxxxxx>
  • Date: Tue, 17 Jun 2008 11:32:26 +0530 (IST)
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 16 Jun 2008 23:02:54 -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=KJY/GlkGhdSPN0WA2Txr/tgU7BZ7urVedPeZQ4b3bnirZ1/x/yFAWQoHJyj4xiv3lB6/C0hyv3PbilbH/ndmrZRMyTCFODYzhaL+AW4094YpLGHhXZWRhktyIYPbm0xGrPLIpW+JI+sEjSmH42Gjp4mCRERGrtC3uU2hwnjeL68=;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

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