This adds support for channel declarations of the form:
channel = [ "name=...,connection=...[,path=...][,backend=...]" ]
where 'name' is a label to identify the channel to the frontend.
If 'connection = pty' then the channel is connected to a pty in the
backend domain
If 'connection = socket' then the channel is connected to a Unix domain
socket given by 'path = ...' in the backend domain.
This patch also adds the command:
xl channel-list <domain>
which allows the state of channels to be queried. In particular if
'connection=pty' this will show the path of the pty slave device.
Signed-off-by: David Scott <dave.scott@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
A 'channel':
- is a low-bandwidth private communication channel that resembles
a physical serial port.
- is implemented as a PV console with a well-known string name
which is used to hook the channel to the appropriate software
in the guest (i.e. some kind of guest agent).
- has a backend 'connection' which describes what should happen
to the data.
The following 'connection' types are defined:
* PTY: the I/O surfaces as a pty in the backend domain
* SOCKET: a listening Unix domain socket accepts a connection in
the backend domain and proxies
Channels may be listed but don't currently support hotplug/unplug.
Signed-off-by: David Scott <dave.scott@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The current implementation of libxl__device_console_init does the same
memset() so this is identical for now.
If libxl__device_console_init changes in future (e.g. to prefer a non-zero
default value for some field) then this will continue to work.
Signed-off-by: David Scott <dave.scott@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In a long-running process (such as virt-manager) this might eventually
run the process out of fds.
That qemu argument construction might generate an fd that needs to be
fed to qemu is a bit odd, but we just run with it and provide a
parameter to the qemu argument construction code for this purpose.
There is no need to use the carefd machinery, because leaking the odd
copy of this descriptor into a child unexpectedly forked out of
another thread, is fine. We just don't want to leak it back to the
main process.
Reported-by: ustermann.max@web.de
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When Xen is flushing the TLB for another domain than current, it has to
switch temporarily to the P2M of this domain. If IRQs are enabled, it may
be possible to receive an interrupt that requires the use the P2M of the current
domain, or even temporarily switch to another P2M.
For the former case, the translation would be wrong. For the latter one,
as the handler would restore the current P2M, Xen would flush the wrong domain
TLB.
Thankfully we don't have such interrupt handler, but it may be necessary
in the future to do that during when the user asks to dump domain stack via
a keystroke.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- spelling in the commit log ]
Since the commit 58f0fd8 "xen: arm: handle variable p2m levels in p2m_lookup",
Xen checks that the root_table offset is valid. If not, its unlock the p2m
spinlock before returning an error. But, at this time, the lock has not been
taken.
On Xen built with debug=y, we can get the following stack trace if the guest
use an invalid IPA in hypercall or mess-up the grant-table:
(XEN) Assertion '_raw_spin_is_locked(lock)' failed at xen/include/asm/arm32/spinlock.h:22
...
(XEN) [<0022d1bc>] _spin_unlock+0x2c/0x50 (PC)
(XEN) [<00253264>] p2m_lookup+0x20c/0x230 (LR)
(XEN) [<7ffdfd54>] 7ffdfd54
(XEN) [<002539f4>] gmfn_to_mfn+0x24/0x3c
(XEN) [<0020e4d4>] __get_paged_frame+0x30/0x12c
(XEN) [<00210680>] __acquire_grant_for_copy+0x4e0/0x768
(XEN) [<00212030>] do_grant_table_op+0x13a0/0x2534
(XEN) [<00257b10>] do_trap_hypervisor+0xe10/0x1148
(XEN) [<0025b330>] return_from_trap+0/0x4
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The commit 7471879 "tools: CMDs and APIs for Cache Monitoring Technology"
has introduced a new section but forgot to add '=back'. This will result
a build issue with newer podman:
man/xl.pod.1 around line 1443: You forgot a '=back' before '=head1'
or creating a section "POD ERRORS" with older one.
At the same time, capitalize the title of the section to match the coding
style used within the files.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Commit 063188f4b3 "xen: arm: Add support for the Exynos secure firmware"
introduced code assuming that exynos_smc() would get called with arguments in
certain registers. While the "noinline" attribute guarantees the function to
not get inlined, it does not guarantee that all arguments arrive in the assumed
registers: gcc's interprocedural analysis can result in clone functions to be
created where some of the incoming arguments (commonly when they have constant
values) get replaced by putting in place the respective values inside the
clone.
Xen contains in multiple place of this SMC function: consolidate the function
in a single place and write it in assembly.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reworded commit message as discussed ]
After all this interface specifically exists for guest kernels to learn
about their (virtual) topology. I'm sure I made a comment to this
effect during review, but apparently I then didn't notice that this
never got carried out.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Some cleanups to the documentation-
- Remove unnecessary steps listed to apply ucode using initrd.
- Condense 'Misc notes' section as well
Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Introduced some new xl commands to enable/disable Cache Monitoring
Technology(CMT) feature.
The following two commands is to attach/detach the CMT feature
to/from a certain domain.
$ xl psr-cmt-attach domid
$ xl psr-cmt-detach domid
This command is to display the CMT information, such as L3 cache
occupancy.
$ xl psr-cmt-show cache_occupancy <domid>
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The code in the arm64 version of setup_xenheap_mappings was making
some very confused attempts to handle this but was bogus.
As well as adjusting the mapping to start on a 1GB boundary we also
need to account for the offset between the start of the mapping and
the actual start of the heap when converting between page pointers,
virtual addresses and machine addresses.
I preferred to do this by explicitly accounting for the offset rather
than adding an offset to the frametable because that approach could
potentially waste a large amount of frametable (up to just less than
1GB worth) but also because of issues with converting mfns from
outside the regions considered for pdx initialisation (which are not
1GB aligned) back and forth.
We already have an idea of the distinction between the start of the
direct map and the start of the xenheap in the difference between
DIRECTMAP_VIRT_START and XENHEAP_VIRT_START. Until now these were the
same thing, but now we change XENHEAP_VIRT_START to point to the
actual start of heap not the mapping. Surprisingly there was only one
place which was using the conceptually wrong value.
Also change xenheap_virt_end to a vaddr_t for consistency.
We've been lucky so far that most hardware happens to locate memory
on a 1GB boundary (we did have reports of a system with memory at a
half gig boundary which exhibited failures which I didn't manage to
follow up on successfully). The EFI support has exposed this
shortcoming by the way it handles reserved memory, which has a
similar effect to having memory non-1GB aligned.
arm32 does things differently here due to using a small Xen heap and
a demand mapped domain heap, so isn't affected.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
Cc: Roy Franz <roy.franz@linaro.org>
Cc: Vijay Kilari <vijay.kilari@gmail.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Roy Franz <roy.franz@linaro.org>
I forgot to request this to be done along with the files being moved.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently --with-systemd=DIR1 --with-systemd-modules-load=DIR2 will set
both XEN_SYSTEMD_DIR and XEN_SYSTEMD_MODULES_LOAD to DIR1. The reason is
that both AC_ARG_WITH() use 'systemd' as the name for the internal
variable. As a result the value of the first option is also use as the
value for the second option. Fix this by using another variable name.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ijc -- ran autogen.sh as requested]
The variables should have been removed already in
7ed06911dc ("Remove dead qemu code from
toplevel Makefile"), but I did not spot it at this time.
Now it looks like the intention initially was to let the install-tools
depend on tools/qemu-xen-traditional-dir. But that did not work because
there was the typo in the variables (TGT vs. TARGET), and
CONFIG_QEMU_TRAD was not defined anyway.
So remove QEMU_TRAD_DIR_TARGET and QEMU_XEN_DIR_TARGET because they are
not defined at all.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When xen is configured with --disable-ocamltools then oxenstored will
still be the default if all required ocaml devel packages are installed.
The reason is that xenstored.m4 is included before the ocamltools check.
And xenstored.m4 does not use the result of --disable-ocamltools.
Rearrange the code to check first for the presence of ocaml, then check
--disable-ocamltools and finally decide what sort of xenstored should be
the default.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh as requested]
"machine_halt()" and "machine_restart()" are modified to use PSCI interface
by default if PSCI-0.2 is supported. The "raw_machine_reset()" is also removed
since this is unnecessary.
Also, machine_halt() is modified to add 10ms delay to make sure all auxiliary CPUs
are offlined before calling the shutdown.
For non-PSCI, platform_poweroff() and platform_reset() are used instead.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch adds SMC calls to suport a subset of PSCI-0.2 functions
(PSCI_VERSION, CPU_ON, SYSTEM_OFF, SYSTEM_RESET).
By default, the psci_init() will use PSCI-0.2. Otherwise, it will
use PSCI-0.1 if PSCI-0.2 fails or un-supported.
To add support for PSCI_VERSION, this patch replaces the "bool_t psci_available"
variable with "int psci_ver", which contains the PSCI_VERSION as described in the
PSCI-0.2 spec.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
A stray call to blexit() was in the normal processing path for handling
FDTs specified in the config file, causing the EFI boot code to
unconditionally exit. Remove the blexit() call as it should never
have been here.
Signed-off-by: Roy Franz <roy.franz@linaro.org>
Tested-by: Vijaya Kumar K<Vijaya.Kumar@caviumnetworks.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The "install" rules depends on both "all" and "subdirs-install" and
"all" depends on "subdirs-all". This leads the "install" rules to call
both "subdirs-all" and "subdirs-install" which create a race with two
concurrent `make` within the same directory (systemd) trying to make the
same things (xen.conf) and failing.
Ultimatly, "install" should only depend on the things it needs to
install, and not on "all".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
- reassign_device_ownership() now tears down RMRR mappings (for other
than Dom0)
- to facilitate that, rmrr_identity_mapping() now deals with both
establishing and tearing down of these mappings (the open coded
equivalent in intel_iommu_remove_device() is being replaced at once)
- intel_iommu_assign_device() now unrolls the assignment upon RMRR
mapping errors
- intel_iommu_add_device() now returns consistent values upon RMRR
mapping failures (was: failure when last iteration ran into a
problem, success otherwise)
- intel_iommu_remove_device() no longer special cases Dom0 (it only
ever gets called for devices removed from the _system_, not a domain)
- rmrr_identity_mapping() now returns a proper error indicator instead
of -1 when intel_iommu_map_page() failed
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Vectors 0-15 are reserved, and a physical LAPIC - upon sending or
receiving one - would generate an APIC error instead of doing the
requested action. Make our emulation behave similarly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This reverts commit eac3f5122f.
The "all" target should never depend on "install", it is supposed to only build
not install.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Hvmloader uses the xenstore ring and then tries to reset it back
to its initial state before booting the guest. Occasionally xenstored
will read the ring while it is being zeroed and conclude it has
been corrupted. This prevents PV drivers from loading in the guest.
This patch updates the xenstore ring protocol definition, enabling
a server to advertise additional features to the guest. One such feature
is defined: the ability to cleanly reset the ring including the
higher-level protocol, like an enhanced RESET_WATCHES for rings.
This patch implements the ring reconnection features in oxenstored
and hvmloader, fixing the bug.
This patch also defines an 'invalid' xenstore packet type and uses this
to poison the ring over a reconnect. This will make diagnosing this
bug much easier in future.
Signed-off-by: David Scott <dave.scott@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Jon Ludlam <jonathan.ludlam@citrix.com>
We noticed that, if configured to use syslog as the logging backend, every
single line of access logging (via the syslog C binding) will call stat on
/etc/localtime for 3 times. The rational behind this is probably to detect any
timezone changes over time.
This is a considerable cost we'd like to avoid, given the intensiveness of our
access logging --- we log almost every xenstore status change (for good
reason). Also a running Xen host is rarely a mobile environment, so the little
benefit can hardly justify the cost.
Setting up the TZ environment varialbe can avoid stat calls.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
In previous commit, we moved from exhaustively scanning all domain connections
to only processing those have correctly notified us by events. The benefits are
not only efficiency but also correctness, because it could potentially block an
ill-behaved client and have it waiting on its own mistake. If someone makes a
mistake on this when developing a piece of code, he/she would immediately
notice the problem (as the process being blocked), so that he/she could fix it
rightaway before anything else. Note that the chances of making such mistakes
are rare in reality, because most client code would use the libxenstore library
(which has all the notification logic built in correctly) instead of having to
implement raw accessing from scratch.
On the other hand, we did notice that there were some legacy code that didn't do
the notification correctly. As some code might be still running in wild, it
would be bad if they break by this change (e.g. after an upgrade). This patch
introduces a safe net mechanism to ensure ill-behaved clients continue to work,
but still retain most of the performance benefits here.
* We add a checker to still scan all the rings periodically, so that we can
still pick up these messages at an acceptable frequency.
* Internally, we introduce an io_credit concept for domain connections. It
represents the rounds of ring scan we are going to perform on a domain
connection. For well-behaved connections, this value is changing between 0
and 1; but for connections detected as ill-behaved, we'll bump its credit
to a high value so that we'll unconditionally scan its ring for the next
$n$ rounds. This way, the client won't hiccupped by the interval between
checker's running (especially during periods when it continously interacts
with oxenstored); and oxenstored doesn't have to keep scanning these
rings indefinitely (with the credit running out), as they are usually quite
most of the time.
* We log an message when a domain connection is suspected as ill-behaved.
Enable [info] level logging if you want/need to see it in action. Note that
this information won't be accurate, as false positives are possible due to
time window (e.g. we detect a client has written to the ring and we get no
notificiation from it for the time being, but still the notification could
potentially arrive at some time later). It's no harm to give a domain
connection extra credit though.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
Currently, upon receiving an event, oxenstored will always scan/process all
the domain connections (xs rings), disregarding which domain sent that event.
This is rather costy and inefficient. It also shadows and indulges client
for not correctly communicating with us on message/space availability.
With this patch, oxenstore will only scan/process the domain connections
that have correctly notified us by events or have IO actions leftover from
previous communication.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
Currently in xenstore connection database, we use a hash table of
(domid -> connection) to store domain connections. This allows fast indexing
based on dom ids.
This patch adds another dimention of fast indexing that is based on eventchn
port number. This is useful when doing selective connection processing
based on the port numbers of incoming events.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
Currently we use list to store socket connections. This is fine for smaller
number of connections. But when we scale up, traveling through a list of
hundreds or thousands of connections just to find a single one of them is very
low efficient.
This patch replaces the list with a (Unix.file_descr -> Connection.t) hash table.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
The function process_fdset_with is called on the read set connections first.
During the process, it might destroy a connection and remove it from the
connections database if some errors occur. However, a reference to the same
connection might still exist in the write set, which is awaiting to be
processed next. In this case, a Not_found error will be raised and the process
is aborted.
This patch changes the logic to ignore connections just missing from the
connection database and continue the rest part of the work.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
This allows to fall back to the original Unix.select if preferred. It could be
useful for debugging purposes too.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
To go beyond 1024 fds, we also need to raise the process limitation on max
open fds (usually defaults to 1024).
We need to know the system level max open fds so that we won't go above that.
Simply setting the limit to RLIM_INFINITY doesn't work on Linux 3.x (EPERM), a
patch on this went into the 2.x branch but not 3.x for some reason.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
Currently, oxenstored uses Unix.select underneath, so it doesn't work properly
if given a FD number >= 1024. This is a scalability bottleneck for hosts
running large number of VMs.
To remove this limitation, we implemented a poll-based mechanism but with the
same type signature as the Unix.select currently in use. So these two functions
can be interchangeable at any stage.
Signed-off-by: Zheng Li <dev@zheng.li>
Reviewed-by: David Scott <dave.scott@citrix.com>
David Scott
Olaf Hering
Ian Jackson
Julien Grall
Wei Liu
Jan Beulich
Aravind Gopalakrishnan
Chao Peng
Ian Campbell
Roger Pau Monne
Suravee Suthikulpanit
Roy Franz
Anthony PERARD
Daniel Kiper
Zheng Li
Andrew Cooper