On 19/09/18 19:28, Wei Liu wrote: > On Tue, Sep 18, 2018 at 02:25:04PM +0100, George Dunlap wrote: >> On 09/18/2018 12:32 PM, Juergen Gross wrote: >>> On 18/09/18 13:20, Jan Beulich wrote: >>>>>>> On 18.09.18 at 13:10, <jgr...@suse.com> wrote: >>>>> On 18/09/18 12:32, Jan Beulich wrote: >>>>>>>>> On 18.09.18 at 08:02, <jgr...@suse.com> wrote: >>>>>>> Instead of using binary hypervisor interfaces for new parameters of >>>>>>> domains or cpupools this patch series adds support for generic text >>>>>>> based parameter parsing. >>>>>>> >>>>>>> Parameters are defined via new macros similar to those of boot >>>>>>> parameters. Parsing of parameter strings is done via the already >>>>>>> existing boot parameter parsing function which is extended a little >>>>>>> bit. >>>>>>> >>>>>>> Parameter settings can either be specified in configuration files of >>>>>>> domains or cpupools, or they can be set via new xl sub-commands. >>>>>> >>>>>> Without having looked at any of the patches yet (not even their >>>>>> descriptions) I'm still wondering what the benefit of textual parameters >>>>>> really is: Just like "binary" ones, they become part of the public >>>>>> interface, and hence subsequently can't be changed any more or >>>>>> less than the ones we currently have (in particular, anything valid in >>>>>> a guest config file will imo need to remain to be valid and meaningful >>>>>> down the road). >>>>> >>>>> So lets look what would be needed for adding something like the >>>>> per-domain xpti parameter using binary interfaces: >>>>> >>>>> 1 an extension of some domctl interface, maybe bumping of the domctl >>>>> interface version >>>>> 2 adding the logic to domctl handling >>>>> 3 adding libxc support >>>>> 4 adding libxl support >>>>> 5 adding a new xl sub-command >>>>> 6 adding domain config support >>>>> 7 adding documentation >>>>> >>>>> With my approach only 2 (in a modified form, parameter handling instead >>>>> of domctl, but comparable in the needed effort) and 7 are needed. >>>>> >>>>> So once the framework is in place it is _much_ easier to add new >>>>> features. >>>> >>>> All the above would hold if the individual options were expressed as >>>> e.g. flags in an extensible bit vector. >>> >>> Who would translate the new option into a bit vector? This would be the >>> tools (libxc/libxl/xl), so those need to be modified for each new bit. >> >> A bit vector would only allow on/off; it wouldn't allow you to set >> numeric parameters, for example. >> >> I like the idea of being able to add configuration parameters without >> having a huge amount of boilerplate; and also of being able to backport >> parameters like xpti without having to worry so much about compatibility. >> >> But I'm not a fan of the idea of using a "string blob" to accomplish >> that. It's convenient for the exact use case you seem to be >> contemplating: having a user add the string into the xl config file, and >> having nobody but the hypervisor interpret it. But what about tools >> that may want to set that parameter? Or tools that want to query the >> parameter, or "introspect" on the domain settings or whatever? Now they >> have to have a bunch of code to generate and parse the string code. >> > > Having the ability to query parameters is a must. Suppose you change > some settings while the domain is running, in order to re-create domain > with the same parameter (migration) there must be a way for toolstack to > query the current settings of that domain. I think most if not all > information is retrieved from xen using binary interface. > > Furthermore, if the string blob is not stored in xen, and there isn't a > binary interface for *setting* parameters, toolstack will have to > translate the retrieved binary information into strings again. > > I'm not picky about formats, but please make get and set interfaces > symmetric (use the same representation).
Did you look into the patches, especially patch 10? The parameters set are all stored in domain config via libxl__arch_domain_save_config(). This is skipped only with the user specifying a special flag for "xl domain-set-parameters". Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
