Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/15/2015 12:03 PM, Razvan Cojocaru wrote:
> Added support for a new class of vm_events: VM_EVENT_REASON_REQUEST,
> sent via HVMOP_request_vm_event. The guest can request that a
> generic vm_event (containing only the vm_event-filled guest registers
> as information) be sent to userspace by setting up the correct
> registers and doing a VMCALL. For example, for a 64-bit guest, this
> means: EAX = 34 (hvmop), EBX = 24 (HVMOP_request_vm_event).
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> 
> ---
> Changes since V1:
>  - Using "curr" consistently in hvm_event_requested().
>  - Renamed VM_EVENT_REASON_REQUEST to VM_EVENT_REASON_GUEST_REQUEST.

In the meantime, my colleague Corneliu Zuzu working on an ARM-related
project with Xen has tested my patch and discovered that some registers
get clobbered when Xen is compiled in debug mode and a GUEST_REQUEST
event is being sent out.

Here's the ARM part, in do_trap_hypercall(), xen/arch/arm/traps.c:

1399 #ifndef NDEBUG
1400     /*
1401      * Clobber argument registers only if pc is unchanged, otherwise
1402      * this is a hypercall continuation.
1403      */
1404     if ( orig_pc == regs->pc )
1405     {
1406         switch ( arm_hypercall_table[*nr].nr_args ) {
1407         case 5: HYPERCALL_ARG5(regs) = 0xDEADBEEF;
1408         case 4: HYPERCALL_ARG4(regs) = 0xDEADBEEF;
1409         case 3: HYPERCALL_ARG3(regs) = 0xDEADBEEF;
1410         case 2: HYPERCALL_ARG2(regs) = 0xDEADBEEF;
1411         case 1: /* Don't clobber x0/r0 -- it's the return value */
1412             break;
1413         default: BUG();
1414         }
1415         *nr = 0xDEADBEEF;
1416     }
1417 #endif

Would it be fair to say that HVMOP_request_vm_event should be an
exception to this rule (i.e. something along the lines of "if (
unlikely(r12 == HVMOP_request_vm_event) && orig_pc == regs->pc )",
etc.)? Even in debug mode, a GUEST_REQUEST vm_event should keep the
state of the guest intact.


Thanks,
Razvan

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