This lock is used to protect all userdata files related to a particular
domain, which include but are not limited to domain configuration. A
new "domain-userdata-lock" entry is introduced in libxl registry.
This lock works among different processes and different threads within
the same process.
Locking protocol inspired by Ian Jackson's chiark-utils with-lock-ex. A
file lock is taken with flock(2). If that succeeds that thread fstat the
fd and stat the lock file path. If the device and inode match then the
lock has been successfully acquired. This lock remains acquired until
the lock file gets deleted or released by flock(2). If device and inode
don't match then another thread acquired the lock and deleted the file
in the meantime; lock procedure should restart.
Portability note: this lock utilises flock(2) so a proper implementation
of flock(2) is required -- that is, it should not be implemented with
fcntl(2).
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Autoconf already has appropriate Linux/non-Linux logic for CONFIG_BLKTAP2.
Let LIBXL_BLKTAP inherit directly from CONFIG_BLKTAP2, rather than requiring a
further LIBXL_BLKTAP=n in addition to ./configure --disable-blktap2 to get
libxl to successfully link under Linux.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
As it needs to be, considering that we assign -1 to it (and
that, later, we check for it to be -1), to signify 'all vcpus'.
While at it, fix a coding style nit and improve error reporting.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
OCaml is replacing its own uint32 type with the ISO C99 uint32_t type
in 4.03.0+dev. Ths patch replaces the remaining uses of uint32 with
uint32_t in the ocaml C code for xen.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: David Scott <dave.scott@citrix.com>
With the introduction of the XEN_DOMCTL_setvnumainfo
in patch titled: "xen: vnuma topology and subop hypercalls"
we put in the plumbing here to use from the toolstack. The user
is allowed to call this multiple times if they wish so.
It will error out if the nr_vnodes or nr_vcpus is zero.
Signed-off-by: Elena Ufimtseva <ufimtseva@gmail.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Define xsm_get_vnumainfo hypercall used for domain which
wish to receive vnuma topology. Add xsm hook for
XEN_DOMCTL_setvnumainfo. Also adds basic policies.
Signed-off-by: Elena Ufimtseva <ufimtseva@gmail.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The commit 11dffa2359 "xen: pass kernel initrd to qemu" deprecated these in
favour of build_info->{kernel,ramdisk,cmdline} but missed a couple of uses.
The ARM case breaks guest boot by omitting the command line from the DTB while
the xl SXP one is mostly cosmetic.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Chunyan Liu <cyliu@suse.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
If max_elem is not zero then hypervisor's spinlock_profile_ucopy_elem()
will attempt to copy profile data into user's data buffer. Since this
buffer is explicitly set to (the equivalent of) NULL the copy will fail,
causing xenlockprof to fail as well.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently in xl.cfg, use 'root' and 'extra' to generate the command
line. 'cmdline' could be a more generic equivalent. So, add 'cmdline'
in xl.cfg and let it be preferred. 'root' and 'extra' still works.
But when 'cmdline' is specified, 'root' and 'extra' will be ignored.
[HVM config example]
[snip]
builder="hvm"
device_model_override="/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64"
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
root="/dev/hda2"
extra="console=tty0 console=ttyS0"
[snip]
or:
[snip]
builder="hvm"
device_model_override="/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64"
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
cmdline="root=/dev/hda2 console=tty0 console=ttyS0"
[snip]
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen side patch to support xen HVM direct kernel boot:
support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
which would be deprecated later) in HVM config file, parse config file,
pass -kernel, -initrd, -append parameters to qemu.
It's working with qemu-xen when using the default BIOS (seabios).
[HVM config example]
name="sles11_sp2"
description="None"
uuid="5c84adcc-bd59-788a-96d2-195f9b599cfe"
memory=512
maxmem=512
vcpus=4
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=0
keymap="en-us"
builder="hvm"
device_model_override="/home/cyliu/git/qemu/x86_64-softmmu/qemu-system-x86_64"
kernel="/mnt/vmlinuz-3.0.13-0.27-default"
ramdisk="/mnt/initrd-3.0.13-0.27-default"
root="/dev/hda2"
extra="console=tty0 console=ttyS0"
disk=[ 'file:/mnt/images/sles11_sp2/disk0.raw,hda,w', ]
vif=[ 'mac=00:16:3e:56:af:69,bridge=br0,type=netfront', ]
stdvga=0
vnc=1
vncunused=1
viridian=0
acpi=1
pae=1
serial="pty"
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Allow the "serial" key to accept a list of serial ports, and pass
them in using the new serial_list domain build element.
For backwards compatibility, still accept singleton values.
Also update the xl.cfg manpage.
This patch borrows substantially from the multiple USB device patch
c3a2148192.
Signed-off-by: Ed White <edmund.h.white@intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch allows an HVM domain to be created with multiple serial
ports.
Since the previous interface only allowed the passing of a single
device, this requires us to add a new element to the hvm struct of
libxl_domain_build_info -- serial_list. For API compatibility, the
old element, serial, remains.
If hvm.serial_list is set, each device listed will cause an extra
"-serial [foo]" to be appended to the qemu command line.
Callers may set either hvm.serial or hvm.serial_list, but not
both; libxl will throw an error if both are set.
In order to allow users of libxl to write software compatible with
older versions of libxl, also define LIBXL_HAVE_BUILDINFO_SERIAL_LIST.
If this is defined, callers may use either hvm.serial or
hvm.serial_list; otherwise, only hvm.serial will be available.
This patch borrows substantially from the multiple USB device patch
ac16730d03.
Signed-off-by: Ed White <edmund.h.white@intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fixed wrong path in xendomains init that make it not working, introduced
in commit d8bad9df25 (tools/xendomains:
move to libexec and use a smaller init helper).
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit: c2ba706c "tools/libxc: goto correct label on error paths" by Andrew
Cooper broke Remus in Xen 4.4 or earlier versions that has this commit
backported.
With Remus, this jump essentially discards the current incomplete checkpoint
received by the backup and restore backup from the last complete checkpoint.
This is required for Remus to work and this does not break live migration. It
has been around since Xen 4.0.
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CFLAGS+=-Wall is already provided by Config.mk
WARN_FLAGS is not used.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Arm based virtual machines dom0/guest will request power related functionality
from xen through PSCI interface. This patch implements version 0.2 of
PSCI standard specified by arm for 64bit and 32 bit arm machines.
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- switch include n vpsci.c from asm-arm/event.h to asm/event.h ]
The two MMX/SSE/AVX code blocks failed to update IP properly, and these
as well as get_reg_refix(), which "manually" updated IP so far, failed
to do the TF and RF processing needed at the end of successfully
emulated instructions.
Fix the test utility at once to check IP is properly getting updated,
and while at it macroize the respective code quite a bit, hopefully
making it easier to add further tests when the need arises.
Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com>
Otherwise "./configure --prefix=/usr" still ends up with exec_prefix=/usr/local
and therefore LIBDIR, PRIVATE_PREFIX and PRIVATE_BINDIR still point to
/usr/local/foo.
This was broken in 54f28913a2 "autoconf: xen: move standard path variables to
config/Paths.mk.in" which tried to add code to expand exec_prefix earlier.
Reported-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Since it may not exist when doing e.g. "make clean". There is
existing logic in the makefiles which will raise an error if an
actual build target is invoked without having run configure.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This adds the systemd xen service / module files and integrates
support into the build system.
This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.
When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.
These are originally based on the Fedora systemd files.
Changes made from Fedora's systemd files:
* split sockets into two files to claim different permissions
* Use /bin/sh -c exec to for a simple launcher implementation
* enables systemd socket activation for C xenstored and Ocaml
oxenstored
* use sd_notify(), so change the service to Type=notify, because of
this we remove the PIDFile specification as we don't care for it, and let
systemd do its magic for us, this also means we don't have to fork
so we use --no-fork with systemd
* defines a modules-load.d, its original source file will be shared
between systemd and old init systems
* simplify service files with ConditionVirtualization=xen which uses
the built in systemd virtualization backend detection, these
service files will not be available to start on systems that do not
boot with xen as a hypervisor
* use autoconf to replace @variable@ paths for us which piggy
backs on top of the latest autoconf changes to xen
* removes oxenstored service file in favor of a system variable which
controls which which xentored to use at run time, we avoid multiple
service files this way.
* simplifies startup to not require polling on the sockets
as initial socket management is handled by systemd, we just
take on the socket later once anything pokes at it, a simple nc -U
(as root) on any of the sockets files can activate the service for example.
Anything queued up will be sent to us once we start. Socket activation
should in theory also let us dynamically switch between xenstores but more
importantly we could upgrade xenstored while keeping all active
socket communication queued up, but in order to take advantage of
this we eventually would need to remove the requirement of not being
able to bring down the xenstored. Even though active sockets are
supported since most libxl communication doesn't triggger a check
on the unix socket first administrators are encouraged to enable
the xenstored.service to triggger an initialization of the xenstored
upon bring up. Some systems also never use unix sockets for
communication with the xenstored and as such active sockets will
not be used there.
* allow for xenstored configuration through *either* of these
configuration files:
- /etc/sysconfig/xenstored
- /etc/default/xenstored
The /etc/default/xenstored will let debian based systems do
the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
with sysconfig. We leave these files all commented out by default
though given that for systemd we want to encourage not using them.
* ensures we create the run directory as most systems will likely
be using a tmpfs for run dirs for the pid files
* Some systems define the selinux context in the systemd Option for the
/var/lib/xenstored tmpfs:
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
For the upstream version we remove that and let systems specify the
context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
$XENSTORED_MOUNT_CTX variable, with a default to none.
* takes advantage of the shared xendomains helper for the xendomains
service
* Add the new dom0 that gets kicked off for disk backend access into
its own systemd service associated to xen
We end up with these systemd files:
General requirements:
* proc-xen.mount
* var-lib-xenstored.mount
xenstored:
* xenstored.service
* xenstored.socket
* xenstored_ro.socket
* xenconsoled.service
* xen-qemu-dom0-disk-backend.service.in
Optional:
* xendomains.service
* xen-watchdog.service
As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.
The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.
If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).
Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
As it stands oxenstored will be used by default if ocaml tools are
found, the init system will also try to use oxenstored first if its
found otherwise the cxenstored will be used. Lets simplify the init
script and let users be explicit about the preference through configure.
This adds support to let you be explicit about the xenstored preference,
you can only use one of these two options:
./configure --with-xenstored=xenstored
./configure --with-xenstored=oxenstored
We continue with the old behaviour and default oxenstored will be used
but only if you have ocaml dependencies. Since the xenstored preference
is explicit now and since we require configure substitutions for it we
make use of the AX_XEN_EXPAND_CONFIG() helpers as otherwise substitution
for SBINDIR is not propagated from the top level configuration.
All this allows us to simplify the init script to use the configured
xenstore from the start. We update the sysconfig/default xencommons file
with the paths for the different options though, this can be used by
users to override the default xenstored, this follows the old behaviour
but we now just explicitly provide the full configured paths for users.
As before, changing the xenstore requires a reboot.
In order to help with documentation we update the README with some
details on configure usage refer to the wiki [0] [1] [2] for more elaborate
details.
Since we are now parsing an entry within Paths.mk.in on tools we let
the move the parsing of the file to be the tool's configure.
[0] http://wiki.xen.org/wiki/Xenstored
[1] http://wiki.xen.org/wiki/XenStore
[2] http://wiki.xen.org/wiki/XenStoreReference
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
This will allow us to share the same module list with
systemd, and lets us upkeep it in one place. Document this
while at it on the top level README and expand on the wiki:
http://wiki.xen.org/wiki/Category:Host_Configuration#Kernel_modules
In order to upkeep parallelism builds be explicit about the
requirement to complete all actions before any installation
targets.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
vCPU soft affinity and NUMA-aware scheduling does not have
to be related. However, soft affinity is how NUMA-aware
scheduling is actually implemented, and therefore, by default,
the results of automatic NUMA placement (at VM creation time)
are also used to set the soft affinity of all the vCPUs of
the domain.
Of course, this only happens if automatic NUMA placement is
enabled and actually takes place (for instance, if the user
does not specify any hard and soft affiniy in the xl config
file).
This also takes care of the vice-versa, i.e., don't trigger
automatic placement if the config file specifies either an
hard (the check for which was already there) or a soft (the
check for which is introduced by this commit) affinity.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
To do so, we add the vcpu_soft_affinity array to build_info, and
treat it much like vcpu_hard_affinity. The new config option is
called "cpus_soft".
Note that the vcpu_hard_affinity array, introduced in a previous
patch, and the vcpu_soft_affinity array, introduced here, share
the same LIBXL_HAVE_xxx macro, in libxl.h. That is called
LIBXL_HAVE_BUILDINFO_VCPU_AFFINITY_ARRAYS, and was introduced
together with vcpu_hard_affinity, but only inside a comment.
In this change, we uncomment, and hence properly define it.
In order to avoid having to issue separate calls to
libxl_set_vcpuaffinity() (one for hard affinity and one for soft
affinity) in libxl__build_pre(), in case the caller uses
b_info->cpumap (for the former) and b_info->vcpu_soft_affinity (for
the latter), we also set (again!) a new default for b_info->cpumap.
This allows, from this change on, to always and only deal with
b_info->vcpu_hard_affinity all around libxl internals.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
so that such parsing code can be used for both hard and soft
affinity, the support for which is introduced in the next
change.
This is pure code motion, no functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
and start using the vcpu_hard_affinity array instead. This is done
as when, in a subsequent patch ("libxl/xl: make it possible to
specify soft-affinity in domain config file") we will become able
to deal with soft affinity, code can be shared.
This change also enables more advanced VCPU to PCPU (hard, for now)
affinity specification, in case a list is used, like:
cpus = ["3-4", "2-6,^4"]
What it means is that VCPU 0 must be pinned to PCPU 3,4 and VCPU 1
to PCPUs 2,3,5,6 (before this change, cpus=[xx, yy] only supported
single values). Of course, the old (e.g., cpus=[2, 3]) syntax
continues to work.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Getting happens via `xl vcpu-list', which now looks like this:
# xl vcpu-list -s
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)
Domain-0 0 0 11 -b- 5.4 8-15 / all
Domain-0 0 1 11 -b- 1.0 8-15 / all
Domain-0 0 14 13 -b- 1.4 8-15 / all
Domain-0 0 15 8 -b- 1.6 8-15 / all
vm-test 3 0 4 -b- 2.5 0-12 / 0-7
vm-test 3 1 0 -b- 3.2 0-12 / 0-7
Setting happens by specifying two pCPU masks to the `xl vcpu-pin'
command, the first one will be hard affinity, the second soft
affinity. If only one mask is specified, it is only hard affinity
that is affected. To change only soft affinity, '-' can be used
as the hard affinity mask parameter, and it will be left alone.
xl manual page is updated accordingly.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
... instead of open-coding them or not using them at all. This in
particular fixes a build (and presumably also runtime) problem on old
enough libc due to the recent introduction of a use of O_CLOEXEC. The
other two changes are only of cleanup kind.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This moves all generic path variables to a new the config/Paths.mk.in
input source file to be processed at configure time, tons of files use
these so this just share them. This also paves the way to let us
easily dynamically configure these with autoconf, for now we leave the
same presets as was present before.
This work was prompted by looking for an autoconf way to do
replacements for the hotplug global file, while at it I realized
that a few other files use the same variables and have in places
around the tree the same constructs for generating their own
files. This makes use of the old buildmakevars2file() but generalizes
the definition of the paths at configure time and spreads the
new definitions out throughout the build system.
This has no impact on building the hypervisor and extras/mini-os,
you do not need to, and are not expected to, run configure to build
those targets.
While at it lets add some documentation on the for the two files on
the source file, we can expand further details on the wiki [0].
[0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
This adds systemd socket activation support for the Ocaml xenstored.
Ocaml lacks systemd library support so we provide our own C helpers
as is done with other functionality lacking on Ocaml.
Active sockets enables oxenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
An important difference with socket activation is that systemd will set
FD_CLOEXEC for us on the socket before giving it to us, we'll sprinkly
the Unix.set_close_on_exec for LSB init next as a separate commit.
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Cc: David Scott <dave.scott@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>
Acked-by: Dave Scott <Dave.Scott@citrix.com>
Acked-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
This adds systemd socket activation support for the C xenstored.
Active sockets enable xenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This will be used later for dynamic configuration paths on C code.
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
If domain is created through virsh, then in xl, one could see it
with 'xl list', but with 'xl list --long domU', it reports:
"Domain name must be specified."
The reason is xl config data does not exist but it still tries
to parse_config_data in current code.
Improve list_domain_details:
If len of config data is 0, just pass, do not go forward to
parse_config_data, otherwise, it will meet error like
"Domain name not specified" and exit. This error is not expected,
since if code enters list_domain_details, domain name validness
is already checked and domain does exist.
Length of config data is 0 may means: config data does not exist due
to some reason, like: domain is created by libvirt, or in destroying
domain process config data is cleared but domain fails to clean up.
No matter in which case, list_domain_details could just show empty
info, but not error like "Domain name not specified".
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
When xenconsoled starts, there will be log lines in the Xen console ring from
boot, even though VIRQ_CON_RING is not yet pending.
Add a force option to handle_hv_logs() which bypasses the event channel check,
allowing xenconsoled to drain the Xen boot messages when it starts, rather
than at the first subsequent time that VIRQ_CON_RING becomes set.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The size of the Xen console ring is runtime configurable, so the statically
sized 16k buffer is not necessarily sufficient. Make repeated
xc_readconsolering() hypercalls while Xen managed to completely fill the
provided buffer.
Also, change the buffer to being static to save on stack space.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Wei Liu
Tamas K Lengyel
Andrew Cooper
Dario Faggioli
M A Young
Elena Ufimtseva
Arianna Avanzini
Ian Campbell
Boris Ostrovsky
Chunyan Liu
White, Edmund H
Fabio Fantoni
Yang Hongyang
Olaf Hering
Parth Dixit
Jan Beulich
Luis R. Rodriguez
Roger Pau Monne
Don Slutz