tools/libxl: libxl_list_domain: fix typo in error message

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools/console: reset tty when xenconsole fails

If xenconsole (the client program) fails, it calls err.  This would
previously neglect to reset the user's terminal to sanity.  Use atexit
to do so.

This routinely happens in Xen 4.4 RC5 with pygrub because libxl
writes the value "" to the tty xenstore key when using xenconsole.
After this patch this just results in a harmless error message.

Reported-by: M A Young <m.a.young@durham.ac.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: M A Young <m.a.young@durham.ac.uk>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
v2: Fix whitespace error (reintroduce hard tab)
    Fix commit message not to claim ignorance about root cause
tools/console: xenconsole tolerate tty errors

Since 28d386fc4341 (XSA-57), libxl writes an empty value for the
console tty node, with read-only permission for the guest, when
setting up pv console "frontends".  (The actual tty value is later set
by xenconsoled.)   Writing an empty node is not strictly necessary to
stop the frontend from writing dangerous values here, but it is a good
belt-and-braces approach.

Unfortunately this confuses xenconsole.  It reads the empty value, and
tries to open it as the tty.  xenconsole then exits.

Fix this by having xenconsole treat an empty value the same way as no
value at all.

Also, make the error opening the tty be nonfatal: we just print a
warning, but do not exit.  I think this is helpful in theoretical
situations where xenconsole is racing with libxl and/or xenconsoled.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>

---
v2: Combine two conditions and move the free
libxl: Make libxl_exec tolerate foofd<=2

Make passing 0, 1, or 2 as stdinfd, stdoutfd or stderrfd work
properly.

Also, document the meaning of the fd arguments.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
libxl: hotplug scripts: stdout >& stderr

Plumb hotplug scripts' stdout to stderr.  That way if they print
anything (which really they shouldn't), it won't get mixed up with
the application's stdout.  (Eg, perhaps with an xl migration
stream...)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: hotplug scripts: stdin < /dev/null

Give hotplug scripts /dev/null for stdin.  That way if they try read
anything anything (which really they shouldn't), nothing odd will
happen.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
xentoollog: provide XTL_STDIOSTREAM_PROGRESS_USE_CR

Provide flags
  XTL_STDIOSTREAM_PROGRESS_USE_CR
  XTL_STDIOSTREAM_PROGRESS_NO_CR
to allow the caller to force, or disable, the use of \r-based
overwriting of progress messages.

In the implementation, rename the variable "tty" to "progress_use_cr".

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xl: New -t option ("tty") to force \r-based messages

Provide a new xl global option -t which passes
XTL_STDIOSTREAM_PROGRESS_USE_CR to xentoollog.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xl: migration: pass -t to xl migrate-receive

If we ourselves are using cr-based overwriting for logging to stderr,
pass -t to the migration receiver so that it knows to do the same
(since its stderr is normally the pipe from sshd).

This requires, of course, that the receiver support that option.  This
is OK from a compatibility point of view because we support migration
to newer, but not necessarily to older, versions.  (If unsupported
backwards migration is still desired the use of -s "" allows the
remote invocation rune to be overridden by a command of one's choice.)

This fixes a regression introduced in 2f80ac9c0e8f, where migration
messages from the receiver would not use of the overwriting protocol.

CC: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
xl: Pass -v options on to migration receiver

Compute a -v option to pass to the migration receiver.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

---
v2: Use minmsglevel_default to initialise minmsglevel.
libxl: multidev: Clarify internal API doc comment

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>