Xen devel - Jun 2008 - Query regarding x86_emulate_memop() function

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.

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.

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? 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().

And, if I have to achieve above-mentioned (scenario) functionality which part of
the code I should lookinto/change to achieve that.

I would really appreciate if some could explain me this.

Thanks,
Abhinav




      Bring your gang together. Do your thing. Find your favourite Yahoo! group
at http://in.promos.yahoo.com/groups/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@cam.ac.uk> wrote:
> From: Grzegorz Miłoś <gm281@cam.ac.uk>
> Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function
> To: "Abhinav Srivastava" <abhinavs_iitkgp@yahoo.co.in>
> Cc: xen-devel@lists.xensource.com
> 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@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@yahoo.co.in> 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@cam.ac.uk> wrote:
> 
>> From: Grzegorz Miłoś <gm281@cam.ac.uk>
>> Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function
>> To: "Abhinav Srivastava" <abhinavs_iitkgp@yahoo.co.in>
>> Cc: xen-devel@lists.xensource.com
>> 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@lists.xensource.com
>> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@eu.citrix.com> wrote:
> From: Keir Fraser <keir.fraser@eu.citrix.com>
> Subject: Re: [Xen-devel] Query regarding x86_emulate_memop() function
> To: abhinavs_iitkgp@yahoo.co.in, "Grzegorz Miłoś "
<gm281@cam.ac.uk>
> Cc: xen-devel@lists.xensource.com
> 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@yahoo.co.in> 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@cam.ac.uk> wrote:
> > 
> >> From: Grzegorz Miłoś <gm281@cam.ac.uk>
> >> Subject: Re: [Xen-devel] Query regarding
> x86_emulate_memop() function
> >> To: "Abhinav Srivastava"
> <abhinavs_iitkgp@yahoo.co.in>
> >> Cc: xen-devel@lists.xensource.com
> >> 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@lists.xensource.com
> >> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel