The sole purpose of TEST_COVERAGE macro is to guard the availability of
gcov sysctl. Now we have a proper CONFIG_GCOV, use it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The version of gcc (4.9.2) I use put constructors into .init_array*
section(s). Collect those sections into constructor list as well.
Modify both arm and x86 scripts to keep them in sync.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The highest populated entry in each hypercall table is currently at index 49.
There is no need to extend both to tables to 64 entries.
Range check eax against the hypercall table array size, and use a
BUILD_BUG_ON() to ensure that the hypercall tables don't grow larger than the
args table.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and
c/s d6d67b047 "x86/pv: Merge the pv hypercall tables", this removes the
risk of accidentally updating only one of the tables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables", this
removes the risk of accidentally updating only one of the tables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The x86 multicall handling was previously some very hairy inline assembly, and
is hard to follow and maintain.
Replace the existing do_multicall_call() with arch_do_multicall_call(). The
x86 side needs to handle both compat and non-compat calls, so pass the full
multicall state, rather than just the multicall_entry sub-structure.
On the ARM side, alter the prototype to match, but there is no resulting
functional change. On the x86 side, the implementation is now in plain C.
This allows the removal of both asm/multicall.h header files.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Editing (and indeed, finding) the hypercall tables can be tricky, especially
towards the end where .rept's are used to maintain the correct layout.
Move this all into C, and let the compiler do the hard work.
To do this, xen/hypercall.h and asm-x86/hypercall.h need to contain prototypes
for all the hypercalls; some were previously missing. This in turn requires
some shuffling of definitions and includes.
One difference is that NULL function pointers are used instead of
{,compat_}do_ni_hypercall(), which pv_hypercall() handles correctly. All
ni_hypercall() infrastructure is therefore dropped.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In a similar style to hvm_do_hypercall(). The C version is far easier to
understand and edit than the assembly versions.
There are a few small differences however. The register clobbering values
have changed (to match the HVM side), and in particular clobber the upper
32bits of 64bit arguments. The hypercall and performance counter record are
reordered to increase code sharing between the 32bit and 64bit cases.
The sole callers of __trace_hypercall_entry() were the assembly code. Given
the new C layout, it is more convenient to fold __trace_hypercall_entry() into
pv_hypercall(), and call __trace_hypercall() directly.
Finally, pv_hypercall() will treat a NULL hypercall function pointer as
-ENOSYS, allowing further cleanup.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Editing (and indeed, finding) the hypercall args tables can be tricky,
especially towards the end where .rept's are used to maintain the correct
layout.
Move this all into C, and let the compiler do the hard work. As 0 is the
default value, drop all explicit 0's.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
set_segment_base is the only hypercall exists in only one of the two modes
guests might run in; all other hypercalls are either implemented, or
unimplemented in both modes.
Remove this split, by allowing do_set_segment_base() to be called in the
compat hypercall path. This change will simplify the verification logic in a
later change.
No behavioural change from a guests point of view.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
It will be reused for PV hypercalls in subsequent changes.
* Rename hvm_hypercall_t to hypercall_fn_t
* Introduce hypercall_table_t
Finally, rework the #includes for hypercall.h so it may be included in
isolation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Add a parameter to xencommons configuration file for specifying the
maximum memory size of the xenstore domain.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add a parameter to specify the maximum memory size of the xenstore
domain. In case the xenstore domain supports ballooning it will be
capable to adjust its own size according to its memory needs.
The maximum memory size can be specified as an absolute value in
MiB, as a fraction of the host's memory, or as a combination of
both (the maximum of the absolute and the fraction value):
--maxmem <m> maxmem is <m> MiB
--maxmem <a>/<b> maxmem is hostmem * a / b
--maxmem <m>:<a>/<b> maxmem is max(<m> MiB, hostmem * a / b)
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Blktap2 is effectively dead code for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. Now libxl no longer supports TAP disk backend, appropriate assertions
are added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend in doc
3. Remove relevant entries in MAINTAINERS
A patch to actually remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: George Dunlap <George.Dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Another place where we should try to behave sufficiently close to how
real hardware does; see the code comments.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The two functions monitor_traps and mem_access_send_req duplicate some of the
same functionality. The mem_access_send_req however leaves a lot of the
standard vm_event fields to be filled by other functions.
Remove mem_access_send_req() completely, making use of monitor_traps() to put
requests into the monitor ring. This in turn causes some cleanup around the
old callsites of mem_access_send_req(). We also update monitor_traps to now
include setting the common vcpu_id field so that all other call-sites can ommit
this step.
Finally, this change identifies that errors from mem_access_send_req() were
never checked. As errors constitute a problem with the monitor ring,
crashing the domain is the most appropriate action to take.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.
SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.
This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.
Signed-off-by: He Chen <he.chen@linux.intel.com>
[jbeulich: doc and style adjustments]
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE()
each produce both const and non-const handles,
only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE()
does not). This patch has __DEFINE_COMPAT_HANDLE() also
produce a const handle.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Extend the CPUID monitor event to include EAX and ECX values that were used
when CPUID was executed. This is useful in identifying which leaf was queried.
We also adjust the xen-access output format to more closely resemble the output
of the Linux cpuid tool's raw format.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
There has not been any substantial update to them since 2011. My quick
check shows that they don't work.
Just delete them. It would be easy to resurrect them from git log should
people still need them.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
It only now occurred to me that there's no new hook needed to do so.
Eliminate the two work item comments.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Within compat_memory_op() this needs to be placed in the first switch()
statement, or it ends up being dead code (as that first switch() has a
default case chaining to compat_arch_memory_op()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
So far accesses to Intel MSRs on an AMD system fall through to the
default case, while accesses to AMD MSRs on an Intel system bail (in
the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on
Intel" case match the "Intel MSR on AMD" one.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In the Credit1 hunk of 9f358ddd69 ("xen: Have
schedulers revise initial placement") csched_cpu_pick()
is called without taking the runqueue lock of the
(temporary) pCPU that the vCPU has been assigned to
(e.g., in XEN_DOMCTL_max_vcpus).
However, although 'hidden' in the IS_RUNQ_IDLE() macro,
that function does access the runq (for doing load
balancing calculations). Two scenarios are possible:
1) we are on cpu X, and IS_RUNQ_IDLE() peeks at cpu's
X own runq;
2) we are on cpu X, but IS_RUNQ_IDLE() peeks at some
other cpu's runq.
Scenario 2) absolutely requies that the appropriate
runq lock is taken. Scenario 1) works even without
taking the cpu's own runq lock. That is actually what
happens when when _csched_pick_cpu() is called from
csched_vcpu_acct() (in turn, called by csched_tick()).
Races have been observed and reported (by both XenServer
own testing and OSSTest [1]), in the form of
IS_RUNQ_IDLE() falling over LIST_POISON, because we're
not currently holding the proper lock, in
csched_vcpu_insert(), when scenario 1) occurs.
However, for better robustness, from now on we always
ask for the proper runq lock to be held when calling
IS_RUNQ_IDLE() (which is also becoming a static inline
function instead of macro).
In order to comply with that, we take the lock around
the call to _csched_cpu_pick() in csched_vcpu_acct().
[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02144.html
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
This allows printf format checking to be performed, and for
debugtrace_printk() to evaluate its arguments, even if debugtrace is disabled
at compile time.
No intended change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
* Use %pv or just d%d in preference to the multiple current ways of
presenting the same information.
* Use PRI_mfn instead of opencoding it.
* Drop all explicit use of __func__ from SHADOW_{PRINTK,DEBUG}() calls. The
wrappers already include it.
* Use hex rather than decimal for printing a pagefault error code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Mini-OS apps need to be compiled with the appropriate config settings
of Mini-OS, as there are various dependencies on those settings in
header files included by the apps.
Enhance stubdom Makefile to set the appropriate CPPFLAGS when calling
the apps' make.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: fold in change to Config.mk to update mini-os commit ]
Commit 03814de1d2 ("libxl: Do not trust
frontend for vusb") introduced an error in libxl_device_usbdev_list().
Fix it.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
It is possible, when normalising a PV pagetable that the table has been freed
and reused for something else by the guest.
In such a case, data read might no longer be a pagetable, and fail the
truncation check. However, this should only be fatal if we encounter such a
page in the paused phase.
This check is now consistent with all other checks in the same area.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
cpufeat_mask() yields an unsigned integer constant. As a result, taking its
complement causes zero extention rather than sign extention.
The result is that, when a guest OS has OXSAVE disabled, all features in 1d
are hidden from native CPUID. Amongst other things, this causes the early
code in Linux to find no LAPIC, but for everything to appear fine later when
userspace is up and running.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
- There's no 32-bit displacement in 16-bit addressing mode.
- It is wrong to ASSERT() anything on parts of an instruction fetched
from guest memory.
- The two scaling bits of a SIB byte don't affect whether there is a
scaled index register or not.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Non-debugging message text should be (and is in the cases here)
distinguishable without also logging function names. Debugging message
text, otoh, already includes file name and line number, so also
logging function names is redundant. One relatively pointless debugging
message gets removed altogether. In another case a missing log level
specifier gets added at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Recent enough binutils (2.25 onwards) support --build-id also for
COFF/PE output, and hence we should use that in favor of the original
hack when possible.
This gets complicated by the linker requiring at least one COFF object
file to attach the .buildid section to. Hence the patch introduces a
buildid.ihex (in order to avoid introducing binary files into the repo)
which then gets converted to a binary minimal COFF object (no sections,
no symbols).
Also (to avoid both code fragment going out of sync) remove an unneeded
ALIGN() from xen.lds.S: Adding an equivalent of it to the .buildid
section would cause the _erodata symbol to become associated with the
wrong section again (see commit 0970299de5 ["x86/EFI + Live Patch:
avoid symbol address truncation"]). And it's pointless because the
alignment already gets properly set by the input section(s).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Contrary to c/s b2507fe7 "x86/domctl: Update PV domain cpumasks when setting
cpuid policy", Intel CPUID masks are applied after fast forwarding hardware
state, rather than before. (All behaviour in this regard appears completely
undocumented by both Intel and AMD).
Therefore, a set bit in the MSR causes hardware to be fast-forwarded, while a
clear bit forces the guests view to 0, even if Xen's CR4.OSXSAVE is actually
set.
This allows Xen to provide an architectural view of a guest kernels
CR4.OSXSAVE setting to any native CPUID instruction issused by guest kernel or
userspace, even when masking is used.
The masking value defaults to 1 (if the guest has XSAVE available) to cause
fast-forwarding to occur for the HVM and idle vcpus.
When setting the MSRs, a PV guest kernel's choice of OXSAVE is taken into
account, and clobbered from the MSR if not set. This causes the
fast-forwarding of Xen's CR4 state not to happen.
As a side effect however, levelling potentially need updating on all PV CR4
changes.
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu
Olaf Hering
Andrew Cooper
Juergen Gross
Jan Beulich
Tamas K Lengyel
Marek Marczykowski-Górecki
He Chen
Razvan Cojocaru
Luwei Kang
Dario Faggioli