[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters
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, <jgross@xxxxxxxx> wrote: > >>> On 18/09/18 12:32, Jan Beulich wrote: > >>>>>>> On 18.09.18 at 08:02, <jgross@xxxxxxxx> 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). Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |