Add libxl__device_add to simple write XenStore device conifg
and libxl__device_add_async to update domain configuration
and write XenStore device config asynchroniously.
Almost all devices have similar libxl__device_xxxx_add function.
This generic functions implement same functionality but
using the device handling framework. Th device specific
part such as setting xen store configurationis moved
to set_xenstore_config callback of the device framework.
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Tue, 12 Sep 2017 12:45:13 +0000 (14:45 +0200)]
gnttab: also validate PTE permissions upon destroy/replace
In order for PTE handling to match up with the reference counting done
by common code, presence and writability of grant mapping PTEs must
also be taken into account; validating just the frame number is not
enough. This is in particular relevant if a guest fiddles with grant
PTEs via non-grant hypercalls.
Note that the flags being passed to replace_grant_host_mapping()
already happen to be those of the existing mapping, so no new function
parameter is needed.
This is CVE-2017-14319 / XSA-234.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
tools/xenstore: dont unlink connection object twice
A connection object of a domain with associated stubdom has two
parents: the domain and the stubdom. When cleaning up the list of
active domains in domain_cleanup() make sure not to unlink the
connection twice from the same domain. This could happen when the
domain and its stubdom are being destroyed at the same time leading
to the domain loop being entered twice.
Additionally don't use talloc_free() in this case as it will remove
a random parent link, leading eventually to a memory leak. Use
talloc_unlink() instead specifying the context from which the
connection object should be removed.
This is CVE-2017-14317 / XSA-233.
Reported-by: Eric Chanudet <chanudete@ainfosec.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
George Dunlap [Tue, 12 Sep 2017 12:43:16 +0000 (14:43 +0200)]
xen/mm: make sure node is less than MAX_NUMNODES
The output of MEMF_get_node(memflags) can be as large as nodeid_t can
hold (currently 255). This is then used as an index to arrays of size
MAX_NUMNODE, which is 64 on x86 and 1 on ARM, can be passed in by an
untrusted guest (via memory_exchange and increase_reservation) and is
not currently bounds-checked.
Check the value in page_alloc.c before using it, and also check the
value in the hypercall call sites and return -EINVAL if appropriate.
Don't permit domains other than the hardware or control domain to
allocate node-constrained memory.
This is CVE-2017-14316 / XSA-231.
Reported-by: Matthew Daley <mattd@bugfuzz.com> Signed-off-by: George Dunlap <george.dunlap@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The new wrappers will add more safety when converting an address to a
frame number (either machine or guest). They are already existing for
Arm and could be useful in common code.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Wed, 16 Aug 2017 17:07:27 +0000 (18:07 +0100)]
xen/x86: Replace mandatory barriers with compiler barriers
In this case, rmb() is being used for its compiler barrier property. Replace
it with an explicit barrer() and comment, to avoid it becoming an unnecessary
lfence instruction (when rmb() gets fixed) or looking like an SMP issue.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 7 Sep 2017 16:38:52 +0000 (17:38 +0100)]
x86/mm: Allow map_domain_page_global() to be used during boot
map_domain_page_global() uses vmap under the hood, which is set up immediately
after switching to SYS_STATE_boot. Relax the local_irq_is_enabled() part of
the assertion before Xen has finished booting, so map_domain_page_global() can
be used duing SMP preparation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 8 Sep 2017 14:24:41 +0000 (16:24 +0200)]
hvmloader: dynamically determine scratch memory range for tests
This re-enables tests on configurations where commit 0d6968635c
("hvmloader: avoid tests when they would clobber used memory") forced
them to be skipped.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Wei Liu [Fri, 8 Sep 2017 13:44:33 +0000 (14:44 +0100)]
monitor: switch to plain bool
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Andrew Cooper [Wed, 6 Sep 2017 13:34:04 +0000 (14:34 +0100)]
x86/page: Implement {get,set}_pte_flags() as static inlines
This resolves 11 Coverity issues along the lines of the following:
1600 for ( i = 0; i < NR_RESERVED_GDT_PAGES; i++ )
CID: Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)result_independent_of_operands: ((33U /* 1U |
0x20U */) | (({...}) ? 8388608U /* 1U << 23 */ : 0) | 0x40U | 2U) & 4095
is always 0x63 regardless of the values of its operands. This occurs as
the bitwise second operand of "|".
1601 l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,
1602 l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR_RW));
This is presumably because once preprocessed, the association of joint logic
inside {get,set}_pte_flags() is lost.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Mon, 4 Sep 2017 16:46:16 +0000 (17:46 +0100)]
DEPS handling: Remove absolute paths from references to cwd
In some directories we use gcc on source files elsewhere, to generate
a .o here in the current directory. Eg in tools/libxl/,
gcc -I -o build.o /path/to/libacpi/build.c
We pass -MMD and -MF options to generate a .d file right here.
In the general case this .c file might need to include things from the
directory here, eg libacpi/build.c eventually #includes various
*libxl*.h. We pass gcc -I. for this, which means things from the cwd
where we invoked gcc, not the directory of the #including file.
When we do this, gcc's -MMD output mentions /path/to/libxl/*libxl*.h,
even though it could refer to simply *libxl*.h. This is presumably
because gcc has noticed that `.' in this context must mean relative to
the invocation cwd, not relative to build.c, and gcc doesn't realise
that references in the .d file are also wrt the invocation cwd.
make distinguishes targets purely textually. It will canonicalise a
target name by removing ./ before comparison (so _libxl_types.h and
./_libxl_types.h are considered the same target) but it won't examine
the filesystem. So _libxl_types.h and
/path/to/tools/libxl/_libxl_types.h are different targets.
And, _libxl_types.h is generated from a pattern rule. This pattern
rule is therefore instatiated twice, and the two instances may be run
concurrently - but use the same tempfiles and can therefore fail.
The thing that is wrong here is gcc's choice to output an absolute
path.
We could work around it by adding a rule to teach make about a
relationship between these `two different files'. But this has to be
done for every autogenerated file and is therefore fragile (leaving a
race bug when we get it wrong).
Ideally we would fix the problem by fixing the .d file as it is
generated. But the .d files are generated by many many rules
mentioning $(CC) and $(CFLAGS). (We might in theory pass a bash
process substitution to -MF, but 1. that's not portable to people who
don't have bash and 2. it hangs, anyway.)
So instead we do this conversion at include time. That is, we tell
make to include not the raw .d files, but the sedded ones.
The sedding removes occurrences of ` $PWD/'. We use the shell
variable PWD because the make variable sometimes refers to the xen
toplevel. If gcc's output format should change, then this sed rune
may not work any more, but that doesn't seem very likely.
The rune is only effective for dependencies on files which are exactly
in the current directory, or a subdirectory of it named simply by its
subdirectory name. If there are autogenerated include files which
exist in a sibling (or worse, somewhere completely else), this
approach will not work, because we'd have to figure out what name this
Makefile usually uses to refer to them. Hopefully such things don't
exist.
The indirect variables DEPS_RM and DEPS_INCLUDE are necessary to
preserve the assumptions made in the various Makefiles. Specifically,
xen/ Makefiles assume that it is ok to say DEPS+=something (where
something is in a subdirectory); tools/ Makefiles all used to include
DEPS themselves (but now they include DEPS_INCLUDE); and many
Makefiles tended to explictly rm DEPS (but now rm DEPS_RM).
In the new scheme of things: DEPS is the files that come out of gcc
(or perhaps an assembler or something) and may be assigned to by
Makefiles. DEPS_INCLUDE is the processed form. And DEPS_RM is both
combined, so that they both get cleaned.
We need to explicitly use $(wildcard ) to do the wildcard expansion on
DEPS a bit earlier. If we didn't, then DEPS_INCLUDE would contain
`.*.d2' which would not exist.
Evaluation order: DEPS_RM and DEPS_INCLUDE are recursively expanded
variables, so that although they are defined early (in Config.mk),
their actual values are computed at the time of use, using the value
of DEPS that is prevailing at that time.
Reported-by: Jan Beulich <JBeulich@suse.com> CC: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
I have verified that I haven't missed anything, with this rune:
git-grep '\bDEPS\b'
Reported-by: Jan Beulich <JBeulich@suse.com> CC: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
And editing tools/xenstat/libxenstat/Makefile by hand.
I verified that I didn't miss anything with this rune:
git-grep '\bDEPS\b' | grep -v include |less
Reported-by: Jan Beulich <JBeulich@suse.com> CC: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Ian Jackson [Mon, 4 Sep 2017 16:46:13 +0000 (17:46 +0100)]
DEPS handling: Provide DEPS_RM and DEPS_INCLUDE
These are not used anywhere yet, so no functional change.
Reported-by: Jan Beulich <JBeulich@suse.com> CC: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Wed, 6 Sep 2017 15:33:52 +0000 (11:33 -0400)]
mm: Don't scrub pages while holding heap lock in alloc_heap_pages()
Instead, preserve PGC_need_scrub bit when setting PGC_state_inuse
state while still under the lock and clear those pages later.
Note that we still need to grub the lock when clearing PGC_need_scrub
bit since count_info might be updated during MCE handling in
mark_page_offline().
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Yi Sun [Mon, 4 Sep 2017 11:01:44 +0000 (19:01 +0800)]
tools: change the type of '*nr' in 'libxl_psr_cat_get_info'
Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info'
is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes
this and does related changes.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Yi Sun [Mon, 4 Sep 2017 11:01:43 +0000 (19:01 +0800)]
tools: use '__i386__' and '__x86_64__' to replace PSR macros
The libxl interfaces and related functions are not necessary to be included by
'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86
macros. Furthermore, only compile 'xl_psr.c' under x86.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Suggested-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Wed, 6 Sep 2017 10:32:00 +0000 (12:32 +0200)]
x86: introduce and use setup_force_cpu_cap()
For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse of setup_clear_cpu_cap() instead, but let clearing of features
overrule forced setting of them.
XEN_SMAP being wrong post-boot is a problem specifically for live
patching, as a live patch may need alternative instruction patching
keyed off of that feature flag.
Reported-by: Sarah Newman <security@prgmr.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 1 Sep 2017 17:05:21 +0000 (17:05 +0000)]
xen: Drop asmlinkage everywhere
asmlinkage is defined as nothing on all architectures, and not used
consistently anywhere, even in common code. Remove it all.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Alexandru Isaila [Wed, 30 Aug 2017 09:04:00 +0000 (12:04 +0300)]
common/vm_event: Initialize vm_event lists on domain creation
The patch splits the vm_event into three structures:vm_event_share,
vm_event_paging, vm_event_monitor. The allocation for the
structure is moved to vm_event_enable so that it can be
allocated/init when needed and freed in vm_event_disable.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Jan Beulich [Tue, 5 Sep 2017 15:32:43 +0000 (17:32 +0200)]
x86emul: correct EVEX decoding
While these are latent issues only for now, correct them right away:
- unnamed (in the SDM) EVEX bits need to be set/clear respectively
- EVEX.V' (called RX in our code) needs to uniformly be 1 in non-64-bit
modes,
- EXEX.R' (called R in our code) is uniformly being ignored in
non-64-bit modes.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 5 Sep 2017 15:32:05 +0000 (17:32 +0200)]
x86emul: correct VEX.L handling for VCVT{,T}S{S,D}2SI
Recent changes to the SDM (and XED) have made clear that older hardware
raising #UD when the bit is set was really an erratum. Generalize the
so far AMD-only override.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 5 Sep 2017 15:31:01 +0000 (17:31 +0200)]
x86emul: correct VEX.W handling for non-64-bit VPINSRD
Going though the XED commits from the last couple of months made me
notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non-
64-bit modes, leading to an insertion of stray 32-bits of zero in case
the original instruction had the bit set.
Also remove a pointless fall-through in VPEXTRW handling, bringing
things in line with VPINSRW.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Tue, 5 Sep 2017 08:40:58 +0000 (09:40 +0100)]
x86/emul: Fix the handling of unimplemented Grp7 instructions
Grp7 is abnormally complicated to decode, even by x86's standards, with
{s,l}msw being the problematic cases.
Previously, any value which fell through the first switch statement (looking
for instructions with entirely implicit operands) would be interpreted by the
second switch statement (handling instructions with memory operands).
Unimplemented instructions would then hit the #UD case for having a non-memory
operand, rather than taking the cannot_emulate path.
Consolidate the two switch statements into a single one, using ranges to cover
the instructions with memory operands.
Reported-by: Petre Pircalabu <ppircalabu@bitdefender.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <JBeulich@suse.com>
Jan Beulich [Mon, 4 Sep 2017 14:25:59 +0000 (16:25 +0200)]
x86/p2m-pt: simplify p2m_next_level()
Calculate entry PFN and flags just once. Convert the two successive
main if()-s to and if/else-if chain. Restrict variable scope where
reasonable. Take the opportunity and also make the induction variable
unsigned.
This at once fixes excessive permissions granted in the 2M PTEs
resulting from splitting a 1G one - original permissions should be
inherited instead. This is not a security issue only because all of
this takes no effect anyway, as iommu_hap_pt_share is always false on
AMD systems for all supported branches.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
adjust_guest_l1e(), now being a compiler-visible single unit, is chosen for
out-of-line'ing from its several callsites. The other helpers remain inline.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Mon, 4 Sep 2017 08:29:48 +0000 (09:29 +0100)]
MAINTAINERS: add arch specific public headers to arch file groups
I've recently got sufficiently annoyed by people not applying enough
common sense to get_maintainer.pl output, Cc-ing all REST maintainers
on ARM-only public interface changes.
Sort ARM's xen/ groups of path specifications at the same time.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Wed, 30 Aug 2017 11:41:40 +0000 (12:41 +0100)]
x86/mm: Use mfn_t for make_cr3()
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: George Dunlap <george.dunlap@citrix.com>
Wei Liu [Fri, 1 Sep 2017 14:35:39 +0000 (15:35 +0100)]
x86/mm: merge ptwr and mmio_ro page fault handlers
Provide a unified entry to avoid going through pte look-up, decode and
emulation cycle more than necessary. The path taken is determined by
the faulting address.
Note that the order of checks is changed in the new function, but the
order of the checks is performed shouldn't matter.
The sole caller is changed to use the new function.
No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 1 Sep 2017 16:24:10 +0000 (10:24 -0600)]
domctl/x86: move vMSI related #define-s to public interface
Xen and qemu having identical #define-s (with different names) is a
strong hint that these should be part of the public interface, at the
same time making obvious that any change to the values in an interface
modification (and hence needs suitable care).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Chao Gao [Thu, 31 Aug 2017 05:01:49 +0000 (01:01 -0400)]
xl/libacpi: extend lapic_id() to uint32_t
This patch is to extend lapic_id() to support more vcpus.
Signed-off-by: Chao Gao <chao.gao@intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross [Thu, 10 Aug 2017 11:24:28 +0000 (13:24 +0200)]
libxc: increase maximum migration stream record length
Today the maximum record lenth in a migration stream is 8MB. This
limits the size of a PV domain to a little bit less than 1TB in the
migration case, as the P2M frame list will exceed 8MB in this case.
Raising the record size limit by a factor of 16 allows for domain
sizes of nearly 16TB to be migrated. This ought to be enough.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich [Fri, 1 Sep 2017 09:07:31 +0000 (11:07 +0200)]
x86: mark the entire directmap NX
There's no reason for the first Mb to be excluded here. Enforce the
restriction right in the top level page table entries.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/pvh: remove stale PVHv1 comment from public headers
From the vcpu_guest_context structure. PVHv2 uses it in the same exact
way as HVM guests, and from the hypervisor point of view PVHv2 is not
even a different guest type, so only mention HVM in the public
headers.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Fri, 1 Sep 2017 09:06:21 +0000 (11:06 +0200)]
mm: don't request scrubbing until dom0 is running
There is no need to scrub pages freed during dom0 construction since
once dom0 is ready the heap will be scrubbed by scrub_heap_pages() anyway,
setting scrub_debug at the end.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Fri, 1 Sep 2017 09:05:45 +0000 (11:05 +0200)]
mm: change boot_scrub_done definition
Rename it to the more appropriate scrub_debug and define as a macro
for !CONFIG_SCRUB_DEBUG. This will allow us to get rid of some
ifdefs (here and in the subsequent patch).
Suggested-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Igor Druzhinin [Fri, 1 Sep 2017 09:03:20 +0000 (11:03 +0200)]
hvmloader, libxl: use the correct ACPI settings depending on device model
We need to choose ACPI tables properly depending on the device
model version we are running. Previously, this decision was
made by BIOS type specific code in hvmloader, e.g. always load
QEMU traditional specific tables if it's ROMBIOS and always
load QEMU Xen specific tables if it's SeaBIOS.
This change saves this behavior (for compatibility) but adds
an additional way (xenstore key) to specify the correct
device model if we happen to run a non-default one. Toolstack
bit makes use of it.
The enforcement of BIOS type depending on QEMU version will
be lifted later when the rest of ROMBIOS compatibility fixes
are in place.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function'
are under the scope of the same VT-d unit as the 'Physical Function'.
A 'Physical Function' can be a 'Traditional Function' or an ARI
'Extended Function'. And furthermore, 'Extended Functions' on an
endpoint are under the scope of the same VT-d unit as the 'Traditional
Functions' on the endpoint. To search VT-d unit for a VF, if its PF
isn't an extended function, the BDF of PF should be used. Otherwise
the BDF of a traditional function in the same device with the PF
should be used.
Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'.
But it is conceptually wrong w/o checking whether PF is an extended
function and would lead to match VFs of a RC integrated PF to a wrong
VT-d unit.
This patch overrides VF 'is_extfn' field and uses this field to
indicate whether the PF of this VF is an extended function. The field
helps to use correct BDF to search VT-d unit.
Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com> Signed-off-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Jan Beulich <jbeulich@suse.com> Tested-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Yi Sun [Thu, 31 Aug 2017 08:07:26 +0000 (16:07 +0800)]
x86: remove redundant checks in sysctl.c
In sysctl.c, the return value of 'psr_get_info' has been checked immediately.
So, it is redundant to check the return value again when copy the field to
guest.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Sergej Proskurin [Wed, 30 Aug 2017 11:19:14 +0000 (13:19 +0200)]
xen-access: Correct default value of write-to-CR4 switch
The current implementation configures the test environment to always
trap on writes to the CR4 control register, even on ARM. This leads to
issues as calling xc_monitor_write_ctrlreg on ARM with VM_EVENT_X86_CR4
will always fail.
Andrew Cooper [Wed, 30 Aug 2017 13:18:01 +0000 (14:18 +0100)]
x86/mm: Rearrange guest_get_eff_{,kern_}l1e() to not be void
Coverity complains that gl1e.l1 may be used while uninitialised in
map_ldt_shadow_page(). This isn't actually accurate as guest_get_eff_l1e()
will always write to its parameter.
However, having a void function which returns a 64bit value via pointer is
rather silly. Rearrange the functions to return l1_pgentry_t.
No functional change, but hopefully should help Coverity not to come to the
wrong conclusion.
Bloat-o-meter also reports a modest improvement:
add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-71 (-71)
function old new delta
guest_get_eff_l1e 82 75 -7
mmio_ro_do_page_fault 530 514 -16
map_ldt_shadow_page 501 485 -16
ptwr_do_page_fault 615 583 -32
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Dario Faggioli [Wed, 30 Aug 2017 11:06:22 +0000 (12:06 +0100)]
xen: RCU: avoid busy waiting until the end of grace period.
On the CPU where a callback is queued, cpu_is_haltable()
returns false (due to rcu_needs_cpu() being itself false).
That means the CPU would spin inside idle_loop(), continuously
calling do_softirq(), and, in there, continuously checking
rcu_pending(), in a tight loop.
Let's instead allow the CPU to really go idle, but make sure,
by arming a timer, that we periodically check whether the
grace period has come to an ended. As the period of the
timer, we pick a value that makes thing look like what
happens in Linux, with the periodic tick (as this code
comes from there).
Note that the timer will *only* be armed on CPUs that are
going idle while having queued RCU callbacks. On CPUs that
don't, there won't be any timer, and their sleep won't be
interrupted (and even for CPUs with callbacks, we only
expect an handful of wakeups at most, but that depends on
the system load, as much as from other things).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: Tim Deegan <tim@xen.org> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 30 Aug 2017 11:06:21 +0000 (12:06 +0100)]
xen: RCU: don't let a CPU with a callback go idle.
If a CPU has a callback queued, it must be ready to invoke
it, as soon as all the other CPUs involved in the grace period
has gone through a quiescent state.
But if we let such CPU go idle, we can't really tell when (if!)
it will realize that it is actually time to invoke the callback.
To solve this problem, a CPU that has a callback queued (and has
already gone through a quiescent state itself) will stay online,
until the grace period ends, and the callback can be invoked.
This is similar to what Linux does, and is the second and last
step for fixing the overly long (or infinite!) grace periods.
The problem, though, is that, within Linux, we have the tick,
so, all that is necessary is to not stop the tick for the CPU
(even if it has gone idle). In Xen, there's no tick, so we must
avoid for the CPU to go idle entirely, and let it spin on
rcu_pending(), consuming power and causing overhead.
In this commit, we implement the above, using rcu_needs_cpu(),
in a way similar to how it is used in Linux. This it correct,
useful and not wasteful for CPUs that participate in grace
period, but have not a callback queued. For the ones that
has callbacks, an optimization that avoids having to spin is
introduced in a subsequent change.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 30 Aug 2017 11:06:21 +0000 (12:06 +0100)]
xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.
Xen is a tickless (micro-)kernel, i.e., when a CPU becomes
idle there is no timer tick that will periodically wake the
CPU up.
OTOH, when we imported RCU from Linux, Linux was (on x86) a
ticking kernel, i.e., there was a periodic timer tick always
running, even on idle CPUs. This was bad for power consumption,
but, for instance, made it easy to monitor the quiescent states
of all the CPUs, and hence tell when RCU grace periods ended.
In Xen, that is impossible, and that's particularly problematic
when the system is very lightly loaded, as some CPUs may never
have the chance to tell the RCU core logic about their quiescence,
and grace periods could extend indefinitely!
This has led, on x86, to long (and unpredictable) delays between
RCU callbacks queueing and their actual invokation. On ARM, we've
even seen infinite grace periods (e.g., complate_domain_destroy()
never being actually invoked!). See here:
The first step for fixing this situation is for RCU to record,
at the beginning of a grace period, which CPUs are already idle.
In fact, being idle, they can't be in the middle of any read-side
critical section, and we don't have to wait for their quiescence.
This is tracked in a cpumask, in a similar way to how it was also
done in Linux (on s390, which was tickless already). It is also
basically the same approach used for making Linux x86 tickless,
in 2.6.21 on (see commit 79bf2bb3 "tick-management: dyntick /
highres functionality").
For correctness, wee also add barriers. One is also present in
Linux, (see commit c3f59023, "Fix RCU race in access of nohz_cpu_mask",
although, we change the code comment to something that makes better
sense for us). The other (which is its pair), is put in the newly
introduced function rcu_idle_enter(), right after updating the
cpumask. They prevent races between CPUs going idle during the
beginning of a grace period.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: Tim Deegan <tim@xen.org> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 30 Aug 2017 11:06:20 +0000 (12:06 +0100)]
xen: ARM: suspend the tick (if in use) when going idle.
Since commit 964fae8ac ("cpuidle: suspend/resume scheduler
tick timer during cpu idle state entry/exit"), if a scheduler
has a periodic tick timer, we stop it when going idle.
This, however, is only true for x86. Make it true for ARM as
well.
Dario Faggioli [Wed, 30 Aug 2017 11:06:20 +0000 (12:06 +0100)]
xen: in do_softirq() sample smp_processor_id() only once.
In fact, right now, we read it at every iteration of the loop.
The reason it's done like this is how context switch was handled
on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
However:
1) we don't have IA64 any longer, and all the achitectures that
we do support, are ok with sampling once and for all;
2) sampling at every iteration (slightly) affect performance;
3) sampling at every iteration is misleading, as it makes people
believe that it is currently possible that SCHEDULE_SOFTIRQ
moves the execution flow on another CPU (and the comment,
by reinforcing this belief, makes things even worse!).
Therefore, let's:
- do the sampling only once, and remove the comment;
- leave an ASSERT() around, so that, if context switching
logic changes (in current or new arches), we will notice.
[1] Some more (historical) information here:
http://old-list-archives.xenproject.org/archives/html/xen-devel/2006-06/msg01262.html
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com> Reviewed-by: Tim Deegan <tim@xen.org>
Andrew Cooper [Wed, 23 Aug 2017 17:49:31 +0000 (17:49 +0000)]
x86/pv: map_ldt_shadow_page() cleanup
Switch the return value from int to bool, to match its semantics. Switch its
parameter from a frame offset to a byte offset (simplifying the sole caller)
and allowing for an extra sanity check that the fault is within the LDT limit.
Drop the unnecessary gmfn and okay local variables, and correct the gva
parameter to be named linear. Rename l1e to gl1e, and simplify the
construction of the new pte by simply taking (the now validated) gl1e and
ensuring that _PAGE_RW is set.
Calculate the pte to be updated outside of the spinlock, which halves the size
of the critical region.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 23 Aug 2017 17:51:59 +0000 (17:51 +0000)]
x86/pv: Switch {fill,zap}_ro_mpt() to using mfn_t
And update all affected callers. Fix the fill_ro_mpt() prototype to be bool
like its implementation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 30 Aug 2017 09:05:02 +0000 (11:05 +0200)]
mm: don't hold heap lock in alloc_heap_pages() longer than necessary
Once pages are removed from the heap we don't need to hold the heap
lock. It is especially useful to drop it for an unscrubbed buddy since
we will be scrubbing it.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Alexandru Isaila [Wed, 30 Aug 2017 09:04:13 +0000 (11:04 +0200)]
x86/hvm: allow guest_request vm_events coming from userspace
In some introspection usecases, an in-guest agent needs to communicate
with the external introspection agent. An existing mechanism is
HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
like all other hypercalls.
Introduce a mechanism whereby the introspection agent can whitelist the
use of HVMOP_guest_request_vm_event directly from userspace.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Roger Pau Monné [Wed, 30 Aug 2017 09:02:24 +0000 (11:02 +0200)]
x86/pt: add a MSI unmask flag to XEN_DOMCTL_bind_pt_irq
The flag is part of the gflags, and should be used to request the
unmask of a MSI interrupt once it's bound.
This is required for the device model in order to be capable of
binding MSIX interrupts that have the entry mask bit already unset at
bind time. Without this fix the interrupts would be left masked.
Note that this commit introduces a change to the domctl, which
requires a bump of the interface version. This is not done here
because the interface version has already been bumped in this release
cycle.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reported by: Andreas Kinzler <hfp@posteo.de> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 28 Aug 2017 15:46:05 +0000 (16:46 +0100)]
x86/pv: Fill all Xen slots in init_guest_l4_table()
There is a bug when using highmem-start= where some L4 directmap slots are not
audited in alloc_l4_table(), and not overwritten by init_guest_l4_table().
As highmem_start is only available in debug builds of the hypervisor, this
does not constitute a security issue.
Ensure that init_guest_l4_table() writes to all of the Xen slots.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Meng Xu [Thu, 3 Aug 2017 02:13:52 +0000 (22:13 -0400)]
xen: rtds: only tickle non-already tickled CPUs
When more than one idle VCPUs that have the same PCPU as their
previous running core invoke runq_tickle(), they will tickle the same
PCPU. The tickled PCPU will only pick at most one VCPU, i.e., the
highest-priority one, to execute. The other VCPUs will not be
scheduled for a period, even when there is an idle core, making these
VCPUs unnecessarily starve for one period.
Therefore, always make sure that we only tickle PCPUs that have not
been tickled already.
Daniel Sabogal [Fri, 25 Aug 2017 21:35:47 +0000 (17:35 -0400)]
libxl/arm: Fix build on arm64 + acpi
With musl, the build fails with the following errors:
actypes.h:202:2: error: #error unknown ACPI_MACHINE_WIDTH
#error unknown ACPI_MACHINE_WIDTH
^~~~~
actypes.h:207:9: error: unknown type name ‘acpi_native_uint’
typedef acpi_native_uint acpi_size;
^~~~~~~~~~~~~~~~
actypes.h:617:3: error: unknown type name ‘acpi_io_address’
acpi_io_address pblk_address;
^~~~~~~~~~~~~~~
This likely went undetected with glibc builds since glibc
indirectly pulls __BITS_PER_LONG from the linux headers
through a standard header. For musl, this is not the case.
Instead, use BITS_PER_LONG to fix the build.
Signed-off-by: Daniel Sabogal <dsabogalcc@gmail.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monne [Tue, 29 Aug 2017 08:50:24 +0000 (09:50 +0100)]
acpi: set correct address of the control/event blocks in the FADT
Commit 149c6b unmasked an issue long present in Xen: the control/event
block addresses provided in the ACPI FADT table where hardcoded to the
V1 version. This was papered over because hvmloader would also always
set HVM_PARAM_ACPI_IOPORTS_LOCATION to 1 regardless of the BIOS
version.
The most notable issue caused by the above bug was that the QEMU
traditional GPE0 block was out of sync: the address provided in the
FADT didn't match the address QEMU was using.
Note that PM1a and TMR worked fine because the V1 address was
hardcoded in the FADT and HVM_PARAM_ACPI_IOPORTS_LOCATION was
unconditionally set to 1 by hvmloader.
Fix this by passing the address of the control/event blocks to
acpi_build_tables, so the values can be properly set in the FADT table
provided to the guest.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
projects / xen.git / log