This patch implements the new protocol for handling pv consoles and
emulated serials as described in the document docs/misc/console.txt.
The changes are:
- xenconsoled: do not write the pty under serial in xenstore if
xenconsoled is handling a consolepath;
- xenconsole: implement support for an explicit console type parameter;
the parameter can be "pv", to specify that the user wants to
connect to a pv console, or "serial", to specify that the user wants to
connect to an emulated serial. If the type parameter hasn't been
specified be the user, xenconsole tries to guess which type of console
it has to connect to, defaulting to pv console for pv guests and
emulated serial for hvm guests.
- xenconsole: use the new xenstore paths;
- libxl: rename libxl_console_constype to libxl_console_consback:
constype is used to to specify whether qemu or xenconsoled provides the
backend, so I renamed it to libxl_console_consback to make it more
obvious that we are talking about backends;
- libxl: add a new libxl_console_constype to specify if the console is
an emulated serial or a pv console;
- libxl: support the new xenconsole "type" command line parameter;
- libxl: use the "output" node under console in xenstore to tell qemu
where do we want the output of this pv console to go;
- remove the legacy "serialpath" from xenconsoled altogether
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Also: update the QEMU_TAG to pull in the qemu part of these changes.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This will allow us to map and then unlink the file and therefore
delete the process on process exit or explicit unmap.
Using the mmaped versions of these files required rewriting build_pv
to use the xc_dom builder functionality directly rather than through
the xc_linux_build "compatibility layer". (The status of the
xc_linux_build interface as a compatibility layer seems a bit dubious
since all existing callers use it but if anything is going to replace
it then libxl seems like the likely candidate).
I'm not thrilled with the definition of the maps lifecycle. This could
be solved by adding a helper function to explicitly free the toplevel
structure.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
The OCaml xenstored supports the XS_RESTRICT operation, which
deprivileges a dom0 xenstore connection so it can only affect one
domain's entries. Add the relevant definitions to the C libraries
so that callers can use it.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Oxenstored should not try to create the evtchn device, as it:
* creates the wrong name (/dev/xen/eventchn rather than evtchn)
* uses a hard-coded minor number, even though this dynamically
depends on what other misc devices are in the kernel
Remove all this code and just rely on the system to create the device.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
cc1: warnings being treated as errors
xc_lib.c: In function 'xc_domain_get_pfn_list':
xc_lib.c:1217: error: assignment from incompatible pointer type
The XEN_DOMCTL_getmemlist interface has been 32/64 invariante since
13594:30af6cfdb05c and uint64_t is now the correct type for the PFN
list on all word sizes.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
This is quite similar to the mmap functionality available in bigarray
but it's less complicated.
Signed-off-by: Vincent Hanquez <vincent.hanquez@eu.citrix.com>