Re: [Xen-devel] [PATCH V2] x86/hvm: Allow guest_request vm_events coming from userspace

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.16 at 10:06, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> Allow guest userspace code to request that a vm_event be sent out
> via VMCALL. This functionality seems to be handy for a number of
> Xen developers, as stated on the mailing list (thread "[Xen-devel]
> HVMOP_guest_request_vm_event only works from guest in ring0").
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> 
> ---
> Changes since V1:
>  - No longer repeating the check when mode == 8.

Technically this looks correct to me now. Albeit I'm still not really
convinced we actually want to start making exceptions here.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4146,15 +4146,25 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>      switch ( mode )
>      {
>      case 8:        
> +        if ( eax == __HYPERVISOR_hvm_op &&
> +             regs->rdi == HVMOP_guest_request_vm_event )
> +            break;
> +        /* Fallthrough */
>      case 4:
> +        /* Fallthrough */
>      case 2:

At least this one annotation is pointless, but if we decide to commit
the change this can of course be taken care of while committing.

> +        if ( mode != 8 && eax == __HYPERVISOR_hvm_op &&
> +             regs->_ebx == HVMOP_guest_request_vm_event )
> +            break;
>          hvm_get_segment_register(curr, x86_seg_ss, &sreg);
>          if ( unlikely(sreg.attr.fields.dpl) )
>          {
> +        /* Fallthrough */
>      default:

I would hope this annotation to be pointless too, but that would
need to be clarified by someone more familiar with Coverity.

>              regs->eax = -EPERM;
>              return HVM_HCALL_completed;
>          }
> +        /* Fallthrough */
>      case 0:

This one, otoh, looks like it was indeed missing (and Coverity
should have complained).

Jan


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