Re: [Xen-devel] libxl refactoring, call for discussion

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2016-01-25 at 15:38 +0200, Pavlo Suikov wrote:
> Hi everyone,
> 
> I want to bring domain restart question for a discussion. It originates
> from DomD restart, but the solution I am about to offer can be quite
> generic.
> 
> Problem is, domain specification currently holds only frontend info,
> which is used to generate both frontend and backend entries for a device;
> that means that backend xenstore data is handled not by a domain that
> owns backends, but by a domain that has frontends linked to these
> backends. As a result, reboot of any domain with backends without reboot
> of the corresponding frontend domains is impossible.
> 
> This is wrong on many levels, but the main thing is: some domains don't
> know something they should (do they have any backends) and some know
> something they should not (there are backends for their frontends in
> different domains).
> 
> I propose following change: make domain "require" and "provide"
> interfaces visible (think CORBA), hold connections between the two in the
> priveleged domain (where toolstack is, think controller from the MVC
> idiom). With this change domains (except for Dom0 which is a special
> case) can be rebooted in any order whatsoever, and frontend/backend link
> can be adjusted as a static config or during runtime (e.g. if hardware
> rendering backend hangs, switch to software rendering to avoid glitches).
> However, it requires change in the libxl internal device representation
> (device should not be a frontend/backend pair any more) and config format
> change, which breaks backwards compatibility.
> 
> That is, I want domain configuration hold records on both frontends (what
> this domain require) and backends (what this domain provides) and libxl
> to create corresponding xenstore branches separately. Moreover, I'd like
> to have frontend/backend connection information be held in a different
> config belonging to Dom0, so that on any domain reboot (or any
> exceptional situation like watchdog failure) supervisor (Dom0) can use
> this information to initiate a reconnect.
> 
> And, as we talk about libxl refactoring, I'd like to state one point
> more: code duplication. Libxl support for a split-driver model consists
> of an declarative IDL device specification, xenstore read, xenstore
> write, config read, config write, xl args read, JSON read/write and
> device chain of responsibility with async device creation. The only thing
> IDL is used for is type and JSON read/write code generation, everything
> else is an error-prone hand-written duplicated code.
> 
> Why won't we generate as much as we can? That means generation of
> xenstore read, xenstore write, config read, config write and xl args read
> - these all directly depend on device IDL specification. If we already
> have external code generation tool, why not use it to full extent instead
> of writing all this serialization/deserialization code manually (and in
> different styles - e.g. block device is the only one that uses lexx, and
> xl_cmdimpl.c parse_config_data implementations differs from device to
> device quite a lot)?

It seems that much of this is conflating several separate things:

   1. The contents of xenstore representing a front/back pair, and the
      protocol which they imply.
   2. The code in libxl which populates that state
   3. The data structures used inside libxl to describe such devices
   4. The code in xl which parses xl's own config file format (which is not
      common to all toolstacks)

Currently only #3 is covered by the IDL.

It's possible (likely even) that some or all of #1 and #2 might be
describable either in an extension to the IDL or in some other domain
specific language or that more of the setup in these cases could be made
common than is the case in the code today, and I would expect such patches
to be welcomed (although it might be wise to discuss a specific plan
first).

Note that for historical reasons their are some subtle differences between
the handling required for some devices.

#4 isn't really subject to the libxl IDL, being xl code relating to xl's
own configuration file. It's possible that xl could benefit from some more
code automation. Wei is looking at cleaning some of the various adhoc
parsing of key-value lists for example (and has posted some patches in the
last week or so). There's probably more cleanup which could be done in this
area and again I would expect patches to be welcome.

It seems like aside from proposing to autogenerate more code you may also
proposing some sort of change to the actual xenstore protocol used by pv
front and backends (the "require"/"provide" concept from CORBA and the MVC
idiom bits). It's not clear to me exactly what the proposal is but just let
me say that (unfortunately) any changes to these arrangements need to be
made in a backward compatible way, we can't simply rework everything and
break all existing guests (or dom0's). Maybe I've misunderstood what you
meant to suggest though.

Note that the xl config file syntax is subject to evolution and can be
extended, or even changed, although we would of course prefer to minimise
breakage where possible (i.e. extending is preferred).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel