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.coop...@citrix.com> 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.coop...@citrix.com> >>> --- >>> CC: Jan Beulich <jbeul...@suse.com> >>> CC: Wei Liu <wei.l...@citrix.com> >>> CC: Stefano Stabellini <sstabell...@kernel.org> >>> CC: Julien Grall <julien.gr...@arm.com> >>> CC: Ian Jackson <ian.jack...@citrix.com> >>> CC: Wei Liu <wei.l...@citrix.com> >>> >>> 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
