Re: [PATCH 00/12] add per-domain and per-cpupool generic parameters

[Wei Liu <wei.liu2@citrix.com>]

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@suse.com> wrote:
> >>> On 18/09/18 12:32, Jan Beulich wrote:
> >>>>>>> On 18.09.18 at 08:02, <jgross@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).

Wei.

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