Re: [Xen-devel] [PATCH] xen: Fix XSM build following c/s 92942fd

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 17:21, <andrew.cooper3@xxxxxxxxxx> wrote:
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

I'm sorry for the breakage / not noticing.

> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Tim Deegan <tim@xxxxxxx>
> CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> CC: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
> 
> Is this actually an appropraite fix?  Software relying on -ENOSYS for Xen
> feature detection is going to break when running under an XSM hypervisor.

That's a valid concern, and it's certainly not nice for XSM to need
tweaking here at all. Perhaps ...

> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1421,7 +1421,6 @@ static int flask_shadow_control(struct domain *d, 
> uint32_t op)
>          break;
>      case XEN_DOMCTL_SHADOW_OP_ENABLE:
>      case XEN_DOMCTL_SHADOW_OP_ENABLE_TEST:
> -    case XEN_DOMCTL_SHADOW_OP_ENABLE_TRANSLATE:
>      case XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION:
>      case XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION:
>          perm = SHADOW__ENABLE;

... rather than just removing the case it should be moved to a
separate case yielding -ENOSYS or -EOPNOTSUPP (right now
shadow_domctl() returns -EINVAL anyway afaics)? (This of
course would mean that we can't completely suppress the
XEN_DOMCTL_SHADOW_OP_ENABLE_TRANSLATE #define in
public/domctl.h. We could limit it to __XEN__ though.)

Jan


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