Re: hvm_emulate_one() usage

Tim Deegan
2013-01-10T14:58:33Z

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.