Add the correct flags for both, libxenlight and libxlutil, when
building xl.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
check-xl-* scripts and data are not libxl- but xl-specific. Move them
from tools/libxl/ to tools/xl/.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There is no need for the sources of libxlutil to include libxl_osdeps.h
as the only dependency is the leading
#define _GNU_SOURCE
in libxl_osdeps.h. So replace including libxl_osdeps.h by the needed
define.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
Today building the libxl internal tests depends on libxlutil having
been built, in spite of the tests not using any functionality of
libxlutil. Fix this by dropping the dependency.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There is no reason why libxenstat is not placed in the tools/libs
directory.
At the same time move xenstat.h to a dedicated include directory
in tools/libs/stat in order to follow the same pattern as the other
libraries in tools/libs.
As now xentop is the only left directory in xenstat move it directly
under tools and get rid of tools/xenstat.
Fix some missing prototype errors (add one prototype and make two
functions static).
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There is no reason why libvchan is not placed in the tools/libs
directory.
At the same time move libxenvchan.h to a dedicated include directory
in tools/libs/vchan in order to follow the same pattern as the other
libraries in tools/libs.
As tools/libvchan now contains no library any longer rename it to
tools/vchan.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There is no reason why libxenstore is not placed in the tools/libs
directory.
The common files between libxenstore and xenstored are kept in the
tools/xenstore directory to be easily accessible by xenstore-stubdom
which needs the xenstored files to be built.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
tools/libxc now contains libxenguest only. Move it to tools/libs/guest.
When generating the pkg-config file for libxenguest a filter is now
required for replacing "xenctrl" by "xencontrol" in the
"Requires.private:" entry. Add this filter to tools/libs/libs.mk.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> (stubdom parts)
Today tools/libxc needs to be built after tools/libs as libxenctrl is
depending on some libraries in tools/libs. This in turn blocks moving
other libraries depending on libxenctrl below tools/libs.
So carve out libxenctrl from tools/libxc and move it into
tools/libs/ctrl.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> (stubdom parts)
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> (python parts)
Acked-by: Wei Liu <wl@xen.org>
readnotes.c is including xg_private.h. Now that the xenctrl headers
are structured better this is no longer needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
Sources of libxenctrl and libxenguest are completely entangled. In
practice libxenguest is a user of libxenctrl, so don't let any source
libxenctrl include xg_private.h.
This can be achieved by moving all definitions used by libxenctrl from
xg_private.h to xc_private.h.
Export xenctrl_dom.h as it will now be included by other public
headers.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
For being able to disentangle lixenctrl and libxenguest headers
xc_dom.h will need to be public. Prepare that by renaming xc_dom.h
to xenctrl_dom.h.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wl@xen.org>
Some sources of libxenguest are named xg_*.c and some xc_*.c. Rename
the xc_*.c files to xg_*.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
Move xc_[un]map_domain_meminfo() functions to new source xg_domain.c as
they are defined in include/xenguest.h and should be in libxenguest.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
The last libxc internal used by xen-mfndump.c is the ERROR() macro.
Add a simple definition for that macro to xen-mfndump.c and replace
the libxc private header includes by official ones.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
The definition of PAGE_SIZE comes from xc_private.h, which shouldn't be
used by xen-mfndump.c. Replace PAGE_SIZE by XC_PAGE_SIZE, as
xc_private.h contains:
#define PAGE_SIZE XC_PAGE_SIZE
For the same reason PAGE_SHIFT_X86 needs to replaced with
XC_PAGE_SHIFT.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
xen-mfndump.c is including the libxc private header xg_save_restore.h.
Avoid that by moving the definition of is_mapped() to xen-mfndump.c
(it is used there only) and by duplicating the definition of
M2P_SIZE() in xen-mfndump.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
xen-hptool is including private headers from tools/libxc without any
need. Switch it to use official headers only.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There are quite some places in Makefiles assuming libxenguest and
libxenctrl being built in the same directory via a single Makefile.
Drop this assumption by specifying the dependencies and path variables
for both libraries correctly.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
The pkg-config file for libxenguest is missing the private dependency
on libxenctrl.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
There is not a single wrapper for a libxenguest function defined.
So drop libxenguest from tools/python/setup.py.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Since more than three years now qemu is capable to set the needed
include and library paths for the Xen libraries via pkg-config.
So drop the specification of those paths in tools/Makefile. This will
enable to move libxenctrl away from tools/libxc, as qemu's configure
script has special treatment of this path.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
For each library built two variants of pkg-config files are created
from a per-library template: an "official" one for installation on
the user's system, and one used for building internal tools, like e.g.
qemu.
Instead of the template which is looking very similar for all libraries
generate the pkg-config files directly from make variables.
This will reduce the need to specify some pkg-config file entries in
the templates, as the contents can easily be generated from available
data (e.g. "Version:" and "Requires.private:" entries).
Especially the variant used for building internal tools needs to gain
additional runtime link parameters for the internally used libraries,
as otherwise those won't be found by the users (e.g. qemu).
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
OSSTest has shown an assertion failure:
http://logs.test-lab.xenproject.org/osstest/logs/153906/test-xtf-amd64-amd64-1/serial-rimava1.log
This is because we pass a non-NUL selector into svm_load_segs(), which is
something we must not do, as this path does not load the attributes/limits
from the GDT/LDT.
Drop the {fs,gs}_sel parameters from svm_load_segs() and use 0 instead. This
is acceptable even for non-zero NUL segments, as it is how the IRET
instruction behaves in all CPUs.
Only use the svm_load_segs() path when both FS and GS are NUL, which is the
common case when scheduling a 64bit vcpu with 64bit userspace in context.
Fixes: ad0fd291c5 ("x86/pv: Rewrite segment context switching from scratch")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We're not after any "fall-through" behavior here. Replace the constructs
with ones understood by all conforming shells, including older bash
(problem observed with 3.1.51(1)).
Fixes: b51715f02b ("tools/hotplug/Linux: remove code duplication in vif-bridge")
Fixes: 3683290fc0 ("tools/hotplug: only attempt to call 'ip route' if there is valid command")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Wei Liu <wl@xen.org>
Commit 82c3d15c90 ("minios: Revert recent change and revert to
working minios") switched the used commit for the build of Xen unstable
from master to a rather old commit (the one used for Xen 4.13 instead
of the last one without a known problem).
Switch to Mini-OS commit 051b87bb9c196 instead, which doesn't contain
the problematic modification being reason for switching away from
master.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
In order to get the ROUNDUP macro, or else the build fails. I assume
ROUNDUP would previously get included from a different header.
Seeing as Linux does explicitly include libs.h do the same for
FreeBSD.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
There are multiple bugs with the existing implementation.
On AMD CPUs prior to Zen2, loading a NUL segment selector doesn't clear the
segment base, which is a problem for 64bit code which typically expects to use
a NUL %fs/%gs selector.
On a context switch from any PV vcpu, to a 64bit PV vcpu with an %fs/%gs
selector which faults, the fixup logic loads NUL, and the guest is entered at
the failsafe callback with the stale base.
Alternatively, a PV context switch sequence of 64 (NUL, non-zero base) =>
32 (NUL) => 64 (NUL, zero base) will similarly cause Xen to enter the guest
with a stale base.
Both of these corner cases manifest as state corruption in the final vcpu.
However, damage is limited to to 64bit code expecting to use Thread Local
Storage with a base pointer of 0, which doesn't occur by default.
The context switch logic is extremely complicated, and is attempting to
optimise away loading a NUL selector (which is fast), or writing a 64bit base
of 0 (which is rare). Furthermore, it fails to respect Linux's ABI with
userspace, which manifests as userspace state corruption as far as Linux is
concerned.
Always restore all selector and base state, in all cases.
Leave a large comment explaining hardware behaviour, and the new ABI
expectations. Update the comments in the public headers.
Drop all "segment preloading" to handle the AMD corner case. It was never
anything but a waste of time for %ds/%es, and isn't needed now that %fs/%gs
bases are unconditionally written for 64bit PV guests. In load_segments(),
store the result of is_pv_32bit_vcpu() as it is an expensive predicate now,
and not used in a way which impacts speculative safety.
Reported-by: Andy Lutomirski <luto@kernel.org>
Reported-by: Sarah Newman <srn@prgmr.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The comments in save_segments(), _toggle_guest_pt() and write_cr() are false.
The %fs and %gs bases can be updated at any time by the guest.
As a consequence, Xen's fs_base/etc tracking state is always stale when the
vcpu is in context, and must not be used to complete MSR_{FS,GS}_BASE reads, etc.
In particular, a sequence such as:
wrmsr(MSR_FS_BASE, 0x1ull << 32);
write_fs(__USER_DS);
base = rdmsr(MSR_FS_BASE);
will return the stale base, not the new base. This may cause guest a guest
kernel's context switching of userspace to malfunction.
Therefore:
* Update save_segments(), _toggle_guest_pt() and read_msr() to always read
the segment bases from hardware.
* Update write_cr(), write_msr() and do_set_segment_base() to not not waste
time caching data which is instantly going to become stale again.
* Provide comments explaining when the tracking state is and isn't stale.
This bug has been present for 14 years, but several bugfixes since have built
on and extended the original flawed logic.
Fixes: ba9adb737b ("Apply stricter checking to RDMSR/WRMSR emulations.")
Fixes: c42494acb2 ("x86: fix FS/GS base handling when using the fsgsbase feature")
Fixed: eccc170053 ("x86/pv: Don't have %cr4.fsgsbase active behind a guest kernels back")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The SYSCFG, TOP_MEM1 and TOP_MEM2 MSRs are currently exposed to guests
and writes are silently discarded. Make this explicit in the SVM code
now, and just return default constant values when attempting to read
any of the MSRs, while continuing to silently drop writes.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Such handling consist in checking that no bits have been changed from
the read value, if that's the case silently drop the write, otherwise
inject a fault.
At least Windows guests will expect to write to the MISC_ENABLE MSR
with the same value that's been read from it.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
This reverts commit 696c273f3d.
I was based on the flase assumption that padding fields need no
copying: If native code checks such fields, they of course need
copying in. And if the ABI specifies them to be zero on
completion, we also need to copy them out.
Arm ID_AA64PFR0_EL1 register provides two fields to describe CPU
FP/SIMD implementations. Currently, we exactly know the meaning of
0x0, 0x1 and 0xf of these fields. Xen treats value < 8 as FP/SIMD
features presented. If there is a value 0x2 bumped in the future,
Xen behaviors for value <= 0x1 can also take effect. But what Xen
done for value <= 0x1 may not always cover new value 0x2 required.
We throw these messages to break the silence when Xen detected
unknown FP/SIMD IDs to notice user to check.
Signed-off-by: Wei Chen <wei.chen@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Xen has cpu_has_fp/cpu_has_simd to detect whether the CPU supports
FP/SIMD or not. But currently, these two MACROs only consider value 0
of ID_AA64PFR0_EL1.FP/SIMD as FP/SIMD features enabled. But for CPUs
that support FP/SIMD and half-precision floating-point arithmetic, the
ID_AA64PFR0_EL1.FP/SIMD are 1 (see Arm ARM DDI0487F.b, D13.2.64).
For these CPUs, xen will treat them as no FP/SIMD support, the
vfp_save/restore_state will not take effect.
From the TRM documents of Cortex-A75/A76/N1, we know these CPUs support
basic Advanced SIMD/FP and half-precision floating-point arithmetic. In
this case, on N1/A76/A75 platforms, Xen will always miss the floating
pointer registers save/restore. If different vCPUs are running on the
same pCPU, the floating pointer registers will be corrupted randomly.
This patch fixes Xen on these new cores.
Signed-off-by: Wei Chen <wei.chen@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Commit 858c0be8c2 "xen/arm: Enable CPU Erratum 1165522 for Neoverse"
added a new erratum but forgot to update silicon-errata.txt.
Update the file accordingly to keep track of errata workaround in Xen.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Currently, xen.git#staging does not build in many environments because
of issues with minios master. This regression was introduced in an
uncontrolled manner by an update to mini-os.git#master.
This is because in e013e85143 "config: use mini-os master for
unstable" we switched to tracking minios master in an uncontrolled
manner. At the time we thought it was unlikely that minios changes
would break the Xen build. This turns out to have been overly
optimistic.
Xen currently uses unstable internal interfaces of minios. Until this
can be sorted out, internal changes to minios can require lockstep
changes in Xen.
All this means that "config: use mini-os master for unstable" was
wrong. We should undo it. Instead, we go back to the previous
situation: xen.git names a specific minios commit.
This scheme is the model used for qemu-xen-traditional.
That nailed commit must be updated manually, to have xen.git pick up
changes from minios. If the minios changes require changes in xen.git
too, to avoid breaking the Xen build, they can be made freely in
minios without adverse consequences. When the minios commitid is
updated in xen.git, the corresponding changes to the actual source
files in xen.git should be bundled together.
For example, when minios is fixed, 8d990807ec "stubdom/grub: update
init_netfront() call for mini-os" will need to be reapplied, folded
into the same commit as updates MINIOS_UPSTREAM_REVISION. For now
that commit must be reverted as we are going back to a previous
version of minios.
This reverts commit 8d990807ec.
This reverts commit e013e85143.
CC: Jan Beulich <jbeulich@suse.com>
CC: Costin Lupu <costin.lupu@cs.pub.ro>
CC: Wei Liu <wl@xen.org>
CC: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Ian Jackson <iwj@xenproject.org>
This reverts commit 60db5da62a.
This is in preparation for the planned move to hosting the xenlight
package in a separate repo.
This also fixes a regression when building with a read-only source and
an out-of-tree build.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>
make 3.81 doesn't support multiline variables defined with
define var =
...
endef
Dropping the "=" in the first line will fix the issue.
Fixes: ded08cdfa7 ("tools: generate most contents of library make variables")
Fixes: ddb2934a91 ("stubdom: add correct dependencies for Xen libraries")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
As was already the case for XSM/Flask, avoid generating compat headers
when they're not going to be needed. To address resulting build issues
- move compat/hvm/dm_op.h inclusion to the only source file needing it,
- add a little bit of #ifdef-ary.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Translation macros aren't used (and hence needed) at all (or else a
devicetree_label entry would have been missing), and userlist has been
removed quite some time ago.
No functional change.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The original intention was to ignore padding fields, but the pattern
matched only ones whose names started with an underscore. Also match
fields whose names are in line with the C spec by not having a leading
underscore. (Note that the leading ^ in the sed regexps was pointless
and hence get dropped.)
This requires adjusting some vNUMA macros, to avoid triggering
"enumeration value ... not handled in switch" warnings, which - due to
-Werror - would cause the build to fail. (I have to admit that I find
these padding fields odd, when translation of the containing structure
is needed anyway.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Various additions to the interface did not get mirrored into the compat
handling machinery. Luckily all additions were done in ways not making
any form of translation necessary.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This was forgotten when the subop was added.
Also take the opportunity and move the dm_op_relocate_memory entry in
xlat.lst to its designated place.
No change in the resulting generated code.
Fixes: ca2b511d3f ("x86/ioreq server: add DMOP to map guest ram with p2m_ioreq_server to an ioreq server")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Use a typedef in struct xen_mc also for the two subops "manually"
translated in the handler, just for consistency. No functional
change.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
84e364f2ed ("x86: add CMCI software injection interface") merely made
sure things would build, without any concern about things actually
working:
- despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
wasn't invoked anywhere (which would have lead to recognizing that the
structure appeared to have no fully compatible layout, despite the use
of a 64-bit handle),
- the interface struct itself was neither added to xlat.lst (and the
resulting macro then invoked) nor was any manual checking of
individual fields added.
Adjust compat header generation logic to retain XEN_GUEST_HANDLE_64(),
which is intentionally layed out to be compatible between different size
guests. Invoke the missing checking (implicitly through CHECK_mc).
No change in the resulting generated code.
Fixes: 84e364f2ed ("x86: add CMCI software injection interface")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
As was pointed out by 0e2e54966a ("mm: fix public declaration of
struct xen_mem_acquire_resource"), we're not currently handling structs
correctly that have uint64_aligned_t fields. #pragma pack(4) suppresses
the necessary alignment even if the type did properly survive (which
it also didn't) in the process of generating the headers. Overall,
with the above mentioned change applied, there's only a latent issue
here afaict, i.e. no other of our interface structs is currently
affected.
As a result it is clear that using #pragma pack(4) is not an option.
Drop all uses from compat header generation. Make sure
{,u}int64_aligned_t actually survives, such that explicitly aligned
fields will remain aligned. Arrange for {,u}int64_t to be transformed
into a type that's 64 bits wide and 4-byte aligned, by utilizing that
in typedef-s the "aligned" attribute can be used to reduce alignment.
Additionally, for the cases where native structures get re-used,
enforce suitable alignment via typedef-s (which allow alignment to be
reduced).
This use of typedef-s makes necessary changes to CHECK_*() macro
generation: Previously get-fields.sh relied on finding struct/union
keywords when other compound types were used. We need to use the
typedef-s (guaranteeing suitable alignment) now, and hence the script
has to recognize those cases, too. (Unfortunately there are a few
special cases to be dealt with, but this is really not much different
from e.g. the pre-existing compat_domain_handle_t special case.)
This need to use typedef-s is certainly somewhat fragile going forward,
as in similar future cases it is imperative to also use typedef-s, or
else the CHECK_*() macros won't check what they're supposed to check. I
don't currently see any means to avoid this fragility, though.
There's one change to generated code according to my observations: In
arch_compat_vcpu_op() the runstate area "area" variable would previously
have been put in a just 4-byte aligned stack slot (despite being 8 bytes
in size), whereas now it gets put in an 8-byte aligned location.
There also results some curious inconsistency in struct xen_mc from
these changes - I intend to clean this up later on. Otherwise unrelated
code would also need adjustment right here.
Additionally a note about the apparently superfluous () in
compat-build-header.py: The simpler form
[ r"typedef(.*)@KeeP@(xen_?)?([\w]+)([^\w])",
r"typedef\1\2\3 __attribute__((__aligned__(__alignof(\1compat_\3))))\4" ],
upsets Python up to at least 3.4.6, claiming to be unable to find the
expansion of \2 (at least when it's empty).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Juergen Gross
Andrew Cooper
Jan Beulich
Roger Pau Monne
Wei Chen
Julien Grall
Ian Jackson
George Dunlap