From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for guest-requested events Date: Wed, 24 Jun 2015 17:56:33 +0300 Message-ID: <558AC521.8090606@bitdefender.com> References: <1434359007-9302-1-git-send-email-rcojocaru@bitdefender.com> <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: kevin.tian@intel.com, keir@xen.org, jbeulich@suse.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, suravee.suthikulpanit@amd.com, eddie.dong@intel.com, tim@xen.org, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com, wei.liu2@citrix.com, boris.ostrovsky@oracle.com, ian.jackson@eu.citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org 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 > > --- > 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