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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.11.18 at 15:39, <andrew.cooper3@xxxxxxxxxx> 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.

I like the idea in general; I'm not entirely sure if this will scale with future
additions, as the caller might legitimately expect an explanatory string to
come back in all cases. (Of course absence of an explanation could be
signaled via an empty string.)

Jan



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