Re: [Xen-devel] [PATCH v2 3/5] xen/domain: Stricter configuration checking

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Nov 13, 2018 at 02:39:43PM +0000, Andrew Cooper wrote:
> On 13/11/2018 14:36, Wei Liu wrote:
> > On Tue, Nov 13, 2018 at 07:14:24AM -0700, Jan Beulich wrote:
> >>>>> On 12.11.18 at 17:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> >>> Currently, a number of options passed for domain creation are ignored, or 
> >>> have
> >>> implicit fallback behaviour.  This is bad for forwards compatibility, and 
> >>> for
> >>> end users to be certain that they got the configuration they asked for.
> >>>
> >>> With this change:
> >>>  * ARM now strictly requires that XEN_DOMCTL_CDF_hap is passed.  
> >>> Previously,
> >>>    only XEN_DOMCTL_CDF_hvm_guest was checked.
> >>>  * For x86, requesting HAP without HVM is now prohibited, as the 
> >>> combination
> >>>    makes no sense.
> >>>  * For x86, requesting HAP on a non-HAP capable system will fail, rather 
> >>> than
> >>>    silently fall back to Shadow.
> >>>
> >>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >>> ---
> >>> CC: Jan Beulich <JBeulich@xxxxxxxx>
> >>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> >>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> >>> CC: Julien Grall <julien.grall@xxxxxxx>
> >>> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxx>
> >>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> >>>
> >>> Semi RFC because this may cause a user-visible change in behaviour.  
> >>> However,
> >>> if the user has gone to the effort of specifying hap=1, silently falling 
> >>> back
> >>> to shadow is unexpected, and IMO, a bug.
> >> My view on this to a fair part depends on whether the tool stack
> >> would guard us from actually getting into such a situation in the
> >> hypervisor. Getting an unspecific -EINVAL back without further
> >> help towards diagnosis by the tool stack would make such a
> >> change undesirable imo.
> > If you want toolstack to tell you what goes wrong, this sanitisation
> > function should be shared with the toolstack, and presumably with some
> > if __XEN_TOOLS__ trickeries to return / print out the culprit.
> 
> Some bits of logic could be shared like that, but some can't.
> 
> As a different idea, could we hand back an up-to-128 byte string in the
> failure case?  There is space for that in the domctl.u because we've got
> no other error information we need to propagate backwards.

This sounds plausible. We can even define per domctl-op error types
instead of using a single string.

Wei.

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel