Re: [Xen-devel] [PATCH V2] mem_event: Allow emulating an instruction that caused a page fault

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

> This patch makes it possible to emulate an instruction that triggered
> a page fault (received via the mem_event API). This is done by setting
> the MEM_EVENT_FLAG_EMULATE in mem_event_response_t.flags. The purpose
> of this is to be able to receive several distinct page fault mem_events
> for the same address, and choose which ones are allowed to go through
> from dom0 userspace.
> 
> Signed-off-by: Razvan Cojocaru <rzvncj@xxxxxxxxx>
> 
> diff -r b6195e277da5 -r c5db0882bfcf xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c   Wed Jan 16 14:15:44 2013 +0000
> +++ b/xen/arch/x86/mm/p2m.c   Thu Jan 17 16:01:11 2013 +0200
> @@ -1309,6 +1309,17 @@ bool_t p2m_mem_access_check(paddr_t gpa,
>         }
>     }
> 
> +    if ( v->arch.hvm_vmx.mem_event_emulate )

Lack of mem event support for AMD processors will be fixed as soon as someone 
with interest (and time!) gets going. I don't recall anything fundamental 
standing in the way.

So it's best if you lift this field into the generic hvm level.

> +    {
> +        struct hvm_emulate_ctxt ctx[1] = {};
> +
> +        v->arch.hvm_vmx.mem_event_emulate = 0;
> +        hvm_emulate_prepare(ctx, guest_cpu_user_regs());
Tim's point is that you won't get all the mem events, because the instruction 
can easily touch multiple pages. It's a question that addresses the need for 
this patch in the first place.

One potential (hairy) fix is to have all get_page_from_gfn check for and emit a 
mem event. It's a bit of rat hole, because we'll need to pass the intended 
permissions down the stack, check against mem event status, etc etc. It will 
help extend mem event to catch all hypervisor-based accesses that currently it 
mostly can't, as well as foreign mappings. It's certainly not for the faint of 
heart.

> +        hvm_emulate_one(ctx);
> +
> +        return 1;
> +    }
> +
>     *req_ptr = NULL;
>     req = xzalloc(mem_event_request_t);
>     if ( req )
> @@ -1347,8 +1358,15 @@ void p2m_mem_access_resume(struct domain
>     /* Pull all responses off the ring */
>     while( mem_event_get_response(d, &d->mem_event->access, &rsp) )
>     {
> +        d->vcpu[rsp.vcpu_id]->arch.hvm_vmx.mem_event_emulate = 0;
> +
>         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
>             continue;
> +
> +        /* Mark vcpu for skipping one instruction upon rescheduling */
> +        if ( rsp.flags & MEM_EVENT_FLAG_EMULATE )
> +            d->vcpu[rsp.vcpu_id]->arch.hvm_vmx.mem_event_emulate = 1;
> +
>         /* Unpause domain */
>         if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>             vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> diff -r b6195e277da5 -r c5db0882bfcf xen/include/asm-x86/hvm/vmx/vmcs.h
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h      Wed Jan 16 14:15:44 2013 +0000
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h      Thu Jan 17 16:01:11 2013 +0200
> @@ -125,6 +125,8 @@ struct arch_vmx_struct {
>     /* Remember EFLAGS while in virtual 8086 mode */
>     uint32_t             vm86_saved_eflags;
>     int                  hostenv_migrated;
> +    /* Should we emulate the first instruction on VCPU resume after a 
> mem_event? */
> +    uint8_t              mem_event_emulate;
> };
> 
> int vmx_create_vmcs(struct vcpu *v);
> diff -r b6195e277da5 -r c5db0882bfcf xen/include/public/mem_event.h
> --- a/xen/include/public/mem_event.h  Wed Jan 16 14:15:44 2013 +0000
> +++ b/xen/include/public/mem_event.h  Thu Jan 17 16:01:11 2013 +0200
> @@ -36,6 +36,7 @@
> #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
> #define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
> #define MEM_EVENT_FLAG_DUMMY        (1 << 4)
> +#define MEM_EVENT_FLAG_EMULATE      (1 << 5) /* Emulate the instruction that 
> caused the current mem_event */
Line overflow, better stack the comment on top
Thanks
Andres
> 
> /* Reasons for the memory event request */
> #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */
> 
> 
> 


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