As we've already generated a JSON config for Dom0, print that out when
requested.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Before this change, xl stores domain configuration in "xl" format, which
is in fact a verbatim copy of user supplied domain config.
Now libxl provides a new API to retrieve domain configuration, switch to
that new API, store configuration in JSON format.
Tests done so far (xl.{new,old} denotes xl with{,out} "libxl-json"
support):
1. xl.new create then xl.new save, hexdump saved file: domain config
saved in JSON format
2. xl.new create, xl.new save then xl.old restore: failed on
mandatory flag check
3. xl.new create, xl.new save then xl.new restore: succeeded
4. xl.old create, xl.old save then xl.new restore: succeeded
5. xl.new create then local migrate, receiving end xl.new: succeeded
6. xl.old create then local migrate, receiving end xl.new: succeeded
Note that "xl" config is still supported and handled when restarting a
domain. "xl" config file takes precedence over "libxl-json" in that
case, so that user who uses "config-update" to store new config file
won't have regression. All other scenarios (migration, domain listing
etc.) now use the new API.
Lastly, print out warning when users invoke "config-update" to
discourage them from using this command.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This will be used in later patch for xl to remove its "xl" userdata
file.
Both CTX lock and userdata lock are taken in this API. CTX lock is taken
to maintain locking hierarchy, but it also has a side effect to protect
against R-M-W by other threads. Userdata lock is used to protect against
domain destruction.
In general application should not rely on these internal locks to
protect its own userdata files. It should deploys its own lock if it
cares.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Introduce a new public API to return domain configuration. This returned
configuration can be used to rebuild a domain.
Note that this configuration only describes the configuration necessary
to reproduce the guest visible state and does not necessarily include
specific decisions made by the toolstack regarding its current
incarnation (e.g. disk backend) unless they were specified by the
application when the domain was created.
With this approach we can preserve what user has provided in the
original configuration as well as valuable information from xenstore.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Introduce a helper function which can return both "target" node and
"static-max" node of a domain. Reimplement libxl_get_memory_target using
this helper. libxl__fill_dom0_memory_info is adjusted as well.
This helper will be used in later patch.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
We introduce an intermediate empty state when inserting media into
CDROM. The scheme works like this:
lock json config
write empty state to xenstore
for (;;) {
write user supplied disk to JSON
write disk information to xenstore
}
unlock json config
Bear in mind that all steps can fail. With the proposed scheme, we now
know, if xenstore is empty, then CDROM should be considered empty;
otherwise we should use JSON version of CDROM configuration.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
We update JSON version first, then write to xenstore, so that we
maintain the following invariant: any device which is present in
xenstore has a corresponding entry in JSON.
The workflow is as followed:
lock json config
read json config
update in-memory json config with new entry, replacing
any stale entry
for loop
open xs transaction
check device existence, abort if it exists
write in-memory json config to disk
commit xs transaction
end for loop
unlock json config
Please see comment in libxl_internal.h for correctness proof.
As those routines are called both during domain creation and device
hotplug, we add a flag to indicate whether we need to update JSON
config. This flag is only set to true when we hotplug a device. We
cannot update JSON config during domain creation as JSON config is
committed to disk only when domain creation finishes.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The lock introduced in d2cd9d4f ("libxl: functions to lock / unlock
libxl userdata store") has a bug that can leak the lock file when domain
destruction races with other functions that try to get hold of the lock.
There are several issues:
1. The lock is released too early with libxl__userdata_destroyall
deletes everything in userdata store, including the lock file.
2. The check of domain existence is only done at the beginning of lock
function, by the time the lock is acquired, the domain might have
been gone already.
The effect of this two issues is we can run into such situation:
Process 1 Process 2 domain destruction
# LOCK FUNCTION # LOCK FUNCTION
check domain existence check domain existence
acquire lock (file created)
# LOCK FUNCTION
destroy all files (lock file deleted,
lock released)
acquire lock (file created)
# LOCK FUNCTION destroy domain
# UNLOCK (close fd only)
[ lock file leaked ]
Fix this problem by deploying following changes:
1. Unlink lock file in unlock function.
2. Modify libxl__userdata_destroyall to not delete domain-userdata-lock,
so that the lock remains held until unlock function is called.
3. Check domain still exists when the lock is acquired, unlock if
domain is already gone.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
* Since there would not be 32-bit hypervisor, we do not need
hypervisor_is_64bit() again.
* Remove xen_64bit from xc_cpuid_pv_policy().
* Move conditionals for LM/NX masking into architectural logic.
* Since RDTSCP could be used for both 64-bit and 32-bit architectures,
we do not need the tying to 64-bit in intel_xc_cpuid_policy().
* vmx_cpuid_intercept() has covered SYSCALL masking when vmexit and
original is_64bit or is_pae could not cover whether guest OS is really
in long mode or not. Here to drop the conditionals and leave it to
vmexit handler to do the real work.
Signed-off-by: Zhuo Song <songzhuo.sz@alibaba-inc.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
[ ijc -- inserted missing ) to fix compile error ]
This fixes a bug where if a client shares more than 1 page, the
munmap call fails to clean up everything. A process which does
a lot of sharing and unsharing can run out of resources.
This patch also fixes in-tree callers of
- xc_gntshr_munmap
- xc_gnttab_munmap
to supply page counts rather than lengths.
Signed-off-by: David Scott <dave.scott@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This commit changes the existing libxl code to be sure to grant access
permission to PCI-related I/O memory ranges, while setting up passthrough
of PCI devices specified in the domain's configuration, and to VGA-related
memory ranges, while setting up VGA passthrough (if gfx_passthru = 1 in
the domain's configuration).
As for the latter, the newly-added code does not replace any existing one,
but instead matches the calls to xc_domain_memory_mapping() performed by
QEMU on the path that is executed if gfx passthru is enabled and follows
the registration of a new VGA controller (in register_vga_regions(),
defined in hw/pt-graphics.c). In fact, VGA needs some extra memory
ranges to be mapped with respect to PCI; QEMU expects that access to those
memory ranges is implicitly granted when he calls the hypervisor with the
function xc_domain_memory_mapping(): this commit calls iomem_permission
for it when needed by checking the passthru PCI device's class.
NOTE: the code added by this commit still does not verify if the passthru
of the framebuffer area is being performed for the primary GPU, but
only replicates the behavior of QEMU which is limited to performing
the passthru for all PCI devices of VGA class.
This commit is instrumental to the last one in the series, which will
separate the functions of the iomem_permission and memory_mapping DOMCTLs,
so that requesting an I/O-memory range will not imply that access to such
a range is implicitly granted.
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Paolo Valente <paolo.valente@unimore.it>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Eric Trudeau <etrudeau@broadcom.com>
Cc: Viktor Kleinik <viktor.kleinik@globallogic.com>
Cc: Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>
This small helper is responsible for generating Dom0 JSON config
stub and writing Dom0 xenstore entries. This helpers subsumes two calls
to xenstore-write in xencommons script.
Dom0 UUID is intentionally left untouched, so it is always all
zeros. This makes sure that we don't leak Dom0 stubs across rebooting.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- folded in incremental patch for *BSD ]
Originally the code allowed users to attach the same device more than
once. It just stupidly overwrites xenstore entries. This is bogus as
frontend will be very confused.
Introduce a helper function to check if the device to be written to
xenstore already exists. A new error code is also introduced.
The check and add are within one xs transaction.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The configuration is stored in libxl-json format. It will be used as
template to reconstruct domain configuration during runtime.
There's only one write to disk when domain creation finishes. We
therefore have a window that the domain exists but has no JSON config in
disk. We define this state as domain being created or destroyed. Any
other operations that need to access JSON config should bail.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Introduce a new format in libxl userdata store called "libxl-json". This
file format contains JSON version of libxl_domain_config, generated by
libxl. Applications are not supposed to access this file directly.
Two internal functions to get and set libxl_domain_configuration
are also introduced. Also introduce a new error code to indicate
abnormal state that libxl-json config file is empty.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Originally libxl user data store didn't have lock at all. There could be
such race condition as mentioned by Ian Jackson:
Task 1 Task 2
Creating the domain Trying to shut down
actually create domain
observe domid
start domain destruction
delete all userdata
destroy domain
store the userdata
*** forbidden state created: userdata exists but domain doesn't
*** userdata has been leaked
[ would now bomb out ]
This patch adds in proper locking to libxl user data store. The lock is
associated with a specific domain (i.e. a per-domain lock).
As for locking hierachy, we first take CTX lock (which is implemented
with pthread recursive mutex so even if the application has taken it
we're fine), then take the file lock. These locks are released in
reversed order.
A new libxl error code ERROR_LOCK_FAIL is introduced to describe failure
to acquire locks.
Also factor out libxl__userdata_{retrieve,store}, so that other
functions that already hold the lock can call them to manipulate
user data.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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 ]