Re: [Xen-devel] [PATCH v4 3/3] x86/monitor: don't use hvm_funcs directly

["Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>]

I don't feel very strongly about it, so if you really prefer you can
keep the code as it is, however this looks somewhat counterintuitive to
me, especially when you compare the new condition to the old one, because
...

Yea, this patch is not critical. Jan just requested to use a wrapper for hvm_funcs in the other patch so I figured I might as well fix it everywhere in our code. It's pretty minor stuff.

 

> -            }
>              else
>                  return -EOPNOTSUPP;
>          } else
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index aa8ab8d..9128dff 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -514,6 +514,17 @@ static inline enum hvm_intblk nhvm_interrupt_blocked(struct vcpu *v)
>      return hvm_funcs.nhvm_intr_blocked(v);
>  }
>
> +static inline int hvm_enable_msr_exit_interception(struct domain *d)
> +{
> +    if ( hvm_funcs.enable_msr_exit_interception )
> +    {
> +        hvm_funcs.enable_msr_exit_interception(d);
> +        return 0;
> +    }
> +
> +    return -ENOSYS;
> +}
> +

... I can see no reason why this function should not return bool_t, and
return 1 where it now returns 0, and 0 where it now returns -ENOSYS.

SGTM.

Thanks,

Tamas

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