>>> On 08.08.16 at 10:06, <rcojoc...@bitdefender.com> 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 <rcojoc...@bitdefender.com>
>
> ---
> 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@lists.xen.org
https://lists.xen.org/xen-devel
