On 19/10/18 19:22, Juergen Gross wrote: > On 19/10/2018 18:57, Andrew Cooper wrote: >> In practice, having fine grain control of all the features like would be >> excellent for testing purposes, because it allows you to boot two >> otherwise-identical VMs with one configuration difference between them. >> >> In the spirit of the already in progress domaincreate work, options like >> these should be selectable at domain creation time, and immutable >> thereafter. >> >> That said, there is a plethora of tweakables, and I'm not sure how best >> to expose them. While most (all?) of these options are inherently >> supported (as playing with them simulates what Xen would chose on >> different hardware), I expect there will be ample opportunity for people >> to break their systems if they tweak too much. >> >> Is there liable to be any provision in xl/libxl to have "unstable" >> configuration, which is easily identified as "may stop working / cease >> to exist / become invalid at any point in the future?" >> >> Alternatively, are there any other suggestions for alternative mechanisms? > Per-domain parameters like in my series? You could guard the "dangerous" > ones by a global parameter (boot-time or run-time settable).
I was hoping to separate the discussion of what information should be configurable, from the mechanism we used to provide said information. Using a text-based mechanism suffers from the same stable/unstable issues as xl.cfg, so the same concern applies there. (Also, I have a separate uneasy feeling about having yet more string parsing in the hypervisor, but that is definitely unrelated). ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
