Re: [Xen-devel] hvm_emulate_one() usage

[Tim Deegan <tim@xxxxxxx>]

At 16:31 +0200 on 10 Jan (1357835505), Razvan Cojocaru wrote:
> >>I was very much hoping to be able to do this with only one (page fault)
> >>mem_event per emulated write instruction.
> >
> >I'm sure that can be done.  The trick is to make sure the emulation
> >happens in the guest context (i.e. when the guest is scheduled).  You
> >could do that by (e.g.) defining a new mem_access type 'single-step
> >writes' where a write fault triggers a single-step emulation in the
> >fault handler as well as an asynchronous mem-event.
> 
> That's what I'm doing now (albeit with the plain 
> MEM_EVENT_REASON_VIOLATION) - I'm emulating the write in 
> p2m_mem_access_check(), where I'm in the guest context, just before 
> putting the mem_event in the ring buffer.
> 
> The problem is, I don't want to do that. :) I want to stop certain 
> writes _before_ they happen, and emulating the write instruction there 
> first performs the write, and then notifies dom0 userspace about it.
> The ideal sequence would be: 1. notify userspace about a would-be write, 
> 2. get the reply from userspace, 3. only write if userspace said OK. The 
> point is that I don't know if the write should be allowed to happen or 
> not until userspace replies.

In that case, in your resume handler you could siet a flag in the vcpu
struct to say it should be single-stepped once the next time it's
scheduled, and make your call to hvm_emulate_one() from the vmentry path
somewhere.  Presumably you'd also want to save some state saying exactly
which access permissions the vcpu should be ignoring during the
emulation.

VMX already has similar code for the cases where it has to emulate
real-mode instructions; it sets arch.hvm_vcpu.u.vmx.vmx_emulate and
detects it in vmx/entry.S.  You could do something siilar for other
cases.  But anything you add to the vmenter path would have to be
extremely careful not to add any overhead to the normal case. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel