Juergen Gross [Fri, 27 Jan 2017 11:47:22 +0000 (12:47 +0100)]
xenstore: remove XS_RESTRICT support
XS_RESTRICT and the xenstore library function xs_restrict() have never
been usable in all configurations and there are no known users.
This functionality was thought to limit access rights of device models
to xenstore in order to avoid affecting other domains in case of a
security breech. Unfortunately XS_RESTRICT won't help as current
qemu is requiring access to dom0 only accessible xenstore paths to
work correctly. So this command is useless and should be removed.
In order to avoid problems in the future remove all support for
XS_RESTRICT from xenstore.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: David Scott <dave@recoil.org>
Andrew Cooper [Mon, 6 Feb 2017 13:54:03 +0000 (13:54 +0000)]
xen/mm: Alter is_iomem_page() to use mfn_t
Switch its return type to bool to match its use, and simplify the ARM
implementation slightly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu [Wed, 25 Jan 2017 13:45:39 +0000 (13:45 +0000)]
fuzz/x86emul: update fuzzer
Provide the fuzzer with more ops, and more sophisticated input
structure.
Based on a patch originally written by Andrew and George.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: George Dunlap <george.dunlap@citrix.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu [Mon, 30 Jan 2017 15:02:40 +0000 (15:02 +0000)]
x86emul: use msr definitions in msr-index.h
Change the names used in code according to numeric values. Remove the
now unused macros in x86_emualte.c and fix indentation. This in turns
requires including msr-index.h and removing duplicates in userspace
x86_emulate.c in userspace harness program.
No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu [Mon, 30 Jan 2017 14:00:46 +0000 (14:00 +0000)]
x86emul: use eflags definitions in x86-defns.h
Basically this patch does 's/EFLG_/X86_EFLAGS_/g' and with indentation
fixed up. And remove the duplicates in x86_emualte.c. This in turn
requires userspace test harness to include x86-defns.h. Also remove a
few duplicates in userspace harness program.
No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu [Thu, 2 Feb 2017 16:16:53 +0000 (16:16 +0000)]
xl: track size of diskws with a dedicated counter
The num_disks field can change during guest lifetime. Don't use that as
the size of diskws, use a dedicated counter instead.
Also free diskws and reset diskws to NULL after disabling events so that
it will be automatically re-created when the guest reboots.
Reported-by: Fatih Acar <fatih.acar@gandi.net> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Tested-by: Fatih Acar <fatih.acar@gandi.net>
Jan Beulich [Thu, 2 Feb 2017 14:49:42 +0000 (15:49 +0100)]
compat.h: drop COMPAT_HANDLE_PARAM()
The need for 8844ed299a ("x86/dmop: Fix compat_dm_op() ABI") has made
clear that its presence is actively dangerous. At the hypercall entry
points XEN_GUEST_HANDLE_PARAM() should be used anyway (regardless of
whether these are native or compat entry points), and passing around
handles internally shouldn't use their compat representation either.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Fatih Acar [Mon, 30 Jan 2017 14:33:18 +0000 (15:33 +0100)]
xl: Fix assertion on domain reboot with new configuration
libxl_domain_build_info_dispose is not resetting the type field to LIBXL_DOMAIN_TYPE_INVALID.
Instead, it is memseting the struct to 0 thus when libxl_domain_build_info_init_type is called
after a dispose on the same struct, an assertion is triggered because type != LIBXL_DOMAIN_TYPE_INVALID.
Calling libxl_domain_build_info_init makes sure the type field is correctly initialized.
Signed-off-by: Fatih Acar <fatih.acar@gandi.net> Signed-off-by: Nikita Kozlov <nikita.kozlov@gandi.net> Signed-off-by: Vincent Legout <vincent.legout@gandi.net> Signed-off-by: Baptiste Daroussin <baptiste.daroussin@gandi.net> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monne [Wed, 1 Feb 2017 17:44:55 +0000 (17:44 +0000)]
libs/gnttab: add FreeBSD handlers for the grant-table user-space device
This patch adds the headers and helpers for the FreeBSD gntdev, used in order
to map grants from remote domains and to allocate grants on behalf of the
current domain.
Current code has been tested with the QEMU/Qdisk backend.
Signed-off-by: Akshay Jaggi <akshay1994.leo@gmail.com>
[ added dummy stub for osdep_gnttab_grant_copy ] Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Move PAGE_* back to {linux,freebsd}.c due to breakage in stubdom build.
Boris Ostrovsky [Thu, 2 Feb 2017 11:51:39 +0000 (12:51 +0100)]
acpi: switch to dynamic mapping at SYS_STATE_boot
We can switch ACPI from using fixmap to dynamic mapping as soon as
the system enters SYS_STATE_boot. This will allow us, for example,
to map MADT on systems with large number of processors where the
table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4).
To avoid having a window between system entering SYS_STATE_boot and
vmap area being initialized move vm_init() a little higher.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 2 Feb 2017 11:50:35 +0000 (12:50 +0100)]
x86/HVM: make hvm_find_io_handler() static
This reduces the chance of misuse - calling it must in particular
always be accompanied by calling the corresponding ->complete() hook.
Constify its parameter at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Jan Beulich [Thu, 2 Feb 2017 11:48:59 +0000 (12:48 +0100)]
x86emul: correct behavior for single iteration REP INS/OUTS
The initial operation done on these paths may raise an exception (for
->read_io() that's possible only on the PV path, when the I/O port
access check has been deferred). We have to suppress put_rep_prefix()
updating rCX in that case. From an abstract perspective this also
applies to RETRY being returned.
Reported-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Dario Faggioli [Sat, 28 Jan 2017 01:42:22 +0000 (02:42 +0100)]
xen: credit2: non Credit2 pCPUs are ok during shutdown/suspend.
Commit 7478ebe1602e6 ("xen: credit2: fix shutdown/suspend
when playing with cpupools"), while doing the right thing
for actual code, forgot to update the ASSERT()s accordingly,
in csched2_vcpu_migrate().
In fact, as stated there already, during shutdown/suspend,
we must allow a Credit2 vCPU to temporarily migrate to a
non Credit2 BSP, without any ASSERT() triggering.
Move them down, after the check for whether or not we are
shutting down, where the assumption that the pCPU must be
valid Credit2 ones, is valid.
Dario Faggioli [Wed, 18 Jan 2017 11:32:21 +0000 (12:32 +0100)]
xen/tools: tracing: credits can go negative, so use int.
For Credit2, in both the trace records, inside Xen,
and in their parsing, in xenalyze.
In fact, as it is quite a bit better, in order to
understand how much negative credits have gone for
a certain vCPU, to see an actual negative number,
as compared to a wrapped around unsigned!
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Wed, 18 Jan 2017 01:10:14 +0000 (02:10 +0100)]
xen: credit2: improve debug dump output.
Scheduling information debug dump for Credit2 is hard
to read as it contains the same information repeated
multiple time in different ways.
In fact, in Credit2, CPUs are grouped in runqueus. Before
this change, for each CPU, we were printing the while
content of the runqueue, as shown below:
As it can be seen, all the CPUs print the whole content
of the runqueue they belong to, at the time of their
sampling, and this is cumbersome and hard to interpret!
In new output format we print, for each CPU, only the vCPU
that is running there (if that's not the idle vCPU, in which
case, nothing is printed), while the runqueues content
is printed only once, in a dedicated section.
Note that there still is risk of inconsistency between
what is printed in the 'Runqueue info:' and in 'CPUs info:'
sections. That is unavoidable, as the relevant locks are
released and re-acquired, around each single operation.
At least, the inconsistency is less severe than before.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
xen/arm: acpi: Relax hw domain mapping attributes to p2m_mmio_direct_c
Since the hardware domain is a trusted domain, we extend the
trust to include making final decisions on what attributes to
use when mapping memory regions.
For ACPI configured hardware domains, this patch relaxes the hardware
domains mapping attributes to p2m_mmio_direct_c. This will allow the
hardware domain to control the attributes via its S1 mappings.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
xen/arm: dt: Relax hw domain mapping attributes to p2m_mmio_direct_c
Since the hardware domain is a trusted domain, we extend the
trust to include making final decisions on what attributes to
use when mapping memory regions.
For device-tree configured hardware domains, this patch relaxes
the hardware domains mapping attributes to p2m_mmio_direct_c.
This will allow the hardware domain to control the attributes
via its S1 mappings.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tamas K Lengyel [Fri, 27 Jan 2017 18:25:23 +0000 (11:25 -0700)]
xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
Also expose the xc_domain_cacheflush through xenctrl.h.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tamas K Lengyel [Fri, 9 Dec 2016 19:59:25 +0000 (12:59 -0700)]
p2m: split mem_access into separate files
This patch relocates mem_access components that are currently mixed with p2m
code into separate files. This better aligns the code with similar subsystems,
such as mem_sharing and mem_paging, which are already in separate files. There
are no code-changes introduced, the patch is mechanical code movement.
On ARM we also relocate the static inline gfn_next_boundary function to p2m.h
as it is a function the mem_access code needs access to.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tamas K Lengyel [Fri, 9 Dec 2016 19:59:24 +0000 (12:59 -0700)]
arm/mem_access: adjust check_and_get_page to not rely on current
The only caller of this function is get_page_from_gva which already takes
a vcpu pointer as input. Pass this along to make the function in-line with
its intended use-case.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Andrew Cooper [Fri, 27 Jan 2017 14:16:58 +0000 (14:16 +0000)]
xsm: Permit dom0 to use dmops
c/s 524a98c2ac5 "public / x86: introduce __HYPERCALL_dm_op" gave flask
permisisons for a stubdomain to use dmops, but omitted the case of a device
model running in dom0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Paul Durrant <paul.durrant@citrix.com>
Juergen Gross [Fri, 27 Jan 2017 11:45:18 +0000 (12:45 +0100)]
docs: clarify xl mem-max semantics
The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.
As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Tamas K Lengyel [Wed, 25 Jan 2017 16:12:01 +0000 (09:12 -0700)]
arm/p2m: Fix regression during domain shutdown with active mem_access
The change in commit 438c5fe4f0c introduced a regression for domains where
mem_acces is or was active. When relinquish_p2m_mapping attempts to clear
a page where the order is not 0 the following ASSERT is triggered:
Roger Pau Monne [Thu, 26 Jan 2017 16:18:10 +0000 (16:18 +0000)]
x86/dmar: place the initdata annotation after the variable type
clang cannot cope with the annotation being in the middle of the variable
declaration.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wei Liu [Wed, 25 Jan 2017 10:43:11 +0000 (10:43 +0000)]
flask: fix build after the introduction of DMOP
In 58cbc034 send_irq permission was removed but there was still
reference to it in policy file. Remove the stale reference.
And now we also need dm permission. Add that.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
xsm/build: Further build fixes following the DMop series
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Wei Liu [Wed, 25 Jan 2017 11:14:43 +0000 (11:14 +0000)]
fuzz/libelf: exit with fuzzer function return value
Now the function can return nonzero value. Use that value as exit code
for the stub program. AFL might be able to use such information to
optimise fuzzing process.
Paul Durrant [Wed, 25 Jan 2017 10:42:55 +0000 (10:42 +0000)]
docs/misc: update the meaning of the 'disk unplug' flag
The documentation states that a value of '1' will cause unplug of
emulated IDE disks. This is not quite correct, as QEMU will also unplug
emulated SCSI disks at the same time.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Paul Lai [Thu, 10 Nov 2016 23:45:52 +0000 (15:45 -0800)]
Moving ept code to ept specific files.
Renamed p2m_init_altp2m_helper() to p2m_init_altp2m_ept().
Signed-off-by: Paul Lai <paul.c.lai@intel.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Jan Beulich [Wed, 25 Jan 2017 14:10:21 +0000 (15:10 +0100)]
include: speed up compat header generation
Recent additions to xlat.lst have apparently resulted in Python's
garbage collection getting in the way: I would guess that so far it
managed to re-use previously compiled regular expressions, but with the
higher number of them now can't anymore (at least with default
settings). Do the compilation explicitly. While at it, combine the two
lists, and avoid using re.subn() when re.sub() suffices.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap [Wed, 25 Jan 2017 14:09:55 +0000 (15:09 +0100)]
x86/emulate: don't assume that addr_size == 32 implies protected mode
Callers of x86_emulate() generally define addr_size based on the code
segment. In vm86 mode, the code segment is set by the hardware to be
16-bits; but it is entirely possible to enable protected mode, set the
CS to 32-bits, and then disable protected mode. (This is commonly
called "unreal mode".)
But the instruction decoder only checks for protected mode when
addr_size == 16. So in unreal mode, hardware will throw a #UD for VEX
prefixes, but our instruction decoder will decode them, triggering an
ASSERT() further on in _get_fpu(). (With debug=n the emulator will
incorrectly emulate the instruction rather than throwing a #UD, but
this is only a bug, not a crash, so it's not a security issue.)
Teach the instruction decoder to check that we're in protected mode,
even if addr_size is 32.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Split real mode and VM86 mode handling, as VM86 mode is strictly 16-bit
at all times. Re-base.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 25 Jan 2017 14:08:59 +0000 (15:08 +0100)]
x86emul: correct VEX/XOP/EVEX operand size handling for 16-bit code
Operand size defaults to 32 bits in that case, but would not have been
set that way in the absence of an operand size override.
Reported-by: Wei Liu <wei.liu2@citrix.com> (by AFL fuzzing) Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 20 Jan 2017 13:56:10 +0000 (13:56 +0000)]
x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()
Leaf 0x8000001c contains LWP information. edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation. eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.
The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
reading the data straight out of the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 14:48:57 +0000 (14:48 +0000)]
x86/cpufeatures: Hide Instruction Based Sampling from guests
Xen advertises the IBS feature flag to guests on capable AMD hardware.
However, the PV path in Xen, and both the PV and HVM paths in libxc
deliberately clobber the IBS CPUID leaf.
Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so
guests can't actually use the feature at all.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 13:36:36 +0000 (13:36 +0000)]
x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()
Leaves 8000000b-18 are reserved. Leaf 80000019 is 1G TLB information and leaf
0x8000001a is performance hints. These leaves have previously been hidden
from guests, but are perfectly safe to expose when appicable.
Update libxc to also expose these leaves.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 13:00:32 +0000 (13:00 +0000)]
x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()
The entirety of edx is reserved.
Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.
AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests. Its semantics are not clearly expressed, so
it is explicitly clobbered. ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.
A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.
Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 15:35:08 +0000 (15:35 +0000)]
x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()
Leaf 0x80000005 contains L1 cache/TLB information, 0x80000006 L2 & L3
cache/TLB information, and 0x80000007 Power management information.
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD passes all of the cache/TLB information through to the guest, while most
of of the power management information is explicitly clobbered by the
toolstack.
0x80000007 edx (containing ITSC) is covered by the featureset logic.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 14:47:34 +0000 (14:47 +0000)]
x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()
Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf. For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).
While moving the dynamic adjustments from the legacy path, simplify the shadow
PSE36 adjustment. PAE paging is a prerequisite for enabling long mode, making
the long mode check redundant; the case where it doesn't get short circuited
is the case where it is architecturally 0. Make the same adjustment to the
leaf 1 legacy path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 17 Jan 2017 17:32:50 +0000 (17:32 +0000)]
x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01. Collect this leaf normally in calculate_raw_policy() and expose
it to guests. The leaf is reserved by AMD.
Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all. They are reserved by AMD.
Leaves 8 and 0xc are reserved by both vendors.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 17 Jan 2017 17:08:04 +0000 (17:08 +0000)]
x86/cpuid: Only recalculate the shared feature bits once
With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.
This means that:
* Duplication can be dropped from the automatically generated cpuid data.
* The toolstack need not worry about setting them appropriately.
* They can be dropped from the system maximum featuresets.
While editing gen-cpuid.py, reflow some comments which exceeded the expected
line length.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 17 Jan 2017 16:52:14 +0000 (16:52 +0000)]
x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()
The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x80000000, and to take the domains chosen vendor into account when
clamping maximum value.
The high short vendor information is clobbered or duplicated according to the
chosen vendor.
As a side effect of handing out an audited max_leaf value, the 0x8000001e case
can be dropped from pv_cpuid(), as it outside of the visible range.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Jan Beulich <JBeulich@suse.com>
Andrew Cooper [Thu, 19 Jan 2017 10:26:14 +0000 (10:26 +0000)]
x86/cpufeatures: Expose self-snoop to all guests
Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
to optimise its cache flushing algorithm.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Tested-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 25 Jan 2017 09:51:10 +0000 (10:51 +0100)]
x86/hvm: serialize trap injecting producer and consumer
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
[re-based] Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:49:52 +0000 (10:49 +0100)]
dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:48:25 +0000 (10:48 +0100)]
dm_op: convert HVMOP_set_mem_type
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:47:13 +0000 (10:47 +0100)]
dm_op: convert HVMOP_modified_memory
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
NOTE: This patch also widens the 'domain' parameter of
xc_hvm_set_pci_intx_level() from a uint8_t to a uint16_t.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:43:14 +0000 (10:43 +0100)]
dm_op: convert HVMOP_track_dirty_vram
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:41:35 +0000 (10:41 +0100)]
dm_op: convert HVMOP_*ioreq_server*
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Paul Durrant [Wed, 25 Jan 2017 09:40:51 +0000 (10:40 +0100)]
public / x86: introduce __HYPERCALL_dm_op...
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file for further information.
This patch simply adds the boilerplate for the hypercall.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Suggested-by: Ian Jackson <ian.jackson@citrix.com> Suggested-by: Jennifer Herbert <jennifer.herbert@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Elena Ufimtseva [Wed, 25 Jan 2017 09:38:05 +0000 (10:38 +0100)]
VT-d: add command line option for extra rmrrs
On some platforms firmware fails to specify RMRR regions in ACPI tables and
thus those regions will not be mapped in dom0 or guests and may cause IO
Page Faults and prevent dom0 from booting if "iommu=dom0-strict" option is
specified on the Xen command line.
New Xen command line option rmrr allows to specify such devices and
memory regions. These regions are added to the list of RMRR defined in ACPI
if the device is present in system. As a result, additional RMRRs will be
mapped 1:1 in dom0 with correct permissions.
The above mentioned problems were discovered during the PVH work with
ThinkCentre M and Dell 5600T. No official documentation was found so far
in regards to what devices and why cause this. Experiments show that
ThinkCentre M USB devices with enabled debug port generate DMA read
transactions to the regions of memory marked reserved in host e820 map.
For Dell 5600T the device and faulting addresses are not found yet.
For detailed history of the discussion please check following threads:
http://lists.Xen.org/archives/html/xen-devel/2015-02/msg01724.html
http://lists.Xen.org/archives/html/xen-devel/2015-01/msg02513.html
Format for rmrr Xen command line option:
rmrr=start<-end>=[s1]bdf1[,[s1]bdf2[,...]];start<-end>=[s2]bdf1[,[s2]bdf2[,...]]
For example, for Lenovo ThinkCentre M, use:
rmrr=0xd5d45=0:0:1d.0;0xd5d46=0:0:1a.0
If grub2 used and multiple ranges are specified, ';' should be
quoted/escaped, refer to grub2 manual for more information.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Elena Ufimtseva [Wed, 25 Jan 2017 09:37:43 +0000 (10:37 +0100)]
pci: add wrapper for parse_pci
For sbdf's parsing in RMRR command line, add parse_pci_seg with additional
parameter def_seg. parse_pci_seg will help to identify if segment was
found in string being parsed or default segment was used.
Make a wrapper parse_pci so the rest of the callers are not affected.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Elena Ufimtseva [Wed, 25 Jan 2017 09:37:14 +0000 (10:37 +0100)]
VT-d: separate rmrr addition function
In preparation for auxiliary RMRR data provided on Xen command line,
make RMRR adding a separate function.
Also free memery for rmrr device scope in error path.
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Dario Faggioli [Tue, 17 Jan 2017 17:27:10 +0000 (18:27 +0100)]
xen: sched: simplify ACPI S3 resume path.
In fact, when domains are being unpaused:
- it's not necessary to put the vcpu to sleep, as
they are all already paused;
- it is not necessary to call vcpu_migrate(), as
the vcpus are still paused, and therefore won't
wakeup anyway.
Basically, the only important thing is to call
pick_cpu, to let the scheduler run and figure out
what would be the best initial placement (i.e., the
value stored in v->processor), for the vcpus, as
they come back up, one after another.
Note that this is consistent with what was happening
before this change, as vcpu_migrate() calls pick_cpu.
But much simpler and quicker.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Tue, 17 Jan 2017 17:27:03 +0000 (18:27 +0100)]
xen: sched: impove use of cpumask scratch space in Credit1.
It is ok to use just cpumask_scratch in csched_runq_steal().
In fact, the cpu parameter comes from the cpu local variable
in csched_load_balance(), which in turn comes from cpu in
csched_schedule(), which is smp_processor_id().
While there, also:
- move the comment about cpumask_scratch in the header
where the scratch space is declared;
- spell more clearly (in that same comment) what are the
serialization rules.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Tue, 17 Jan 2017 17:26:55 +0000 (18:26 +0100)]
xen: credit2: fix shutdown/suspend when playing with cpupools.
In fact, during shutdown/suspend, we temporarily move all
the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2
domains, we call csched2_vcpu_migrate(), expects to find the
target pCPU in the domain's pool
Therefore, if Credit2 is the default scheduler and we have
removed pCPU 0 from cpupool0, shutdown/suspend fails like
this:
****************************************
Panic on CPU 8:
Assertion 'svc->vcpu->processor < nr_cpu_ids' failed at sched_credit2.c:1729
****************************************
On the other hand, if Credit2 is the scheduler of another
pool, when trying (still during shutdown/suspend) to move
the vCPUs of the Credit2 domains to pCPU 0, it figures
out that pCPU 0 is not a Credit2 pCPU, and fails like this:
The solution is to recognise the specific situation, inside
csched2_vcpu_migrate() and, considering it is something temporary,
which only happens during shutdown/suspend, quickly deal with it.
Then, in the resume path, in restore_vcpu_affinity(), things
are set back to normal, and a new v->processor is chosen, for
each vCPU, from the proper set of pCPUs (i.e., the ones of
the proper cpupool).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Tue, 17 Jan 2017 17:26:46 +0000 (18:26 +0100)]
xen: credit2: never consider CPUs outside of our cpupool.
In fact, relying on the mask of what pCPUs belong to
which Credit2 runqueue is not enough. If we only do that,
when Credit2 is the boot scheduler, we may ASSERT() or
panic when moving a pCPU from Pool-0 to another cpupool.
This is because pCPUs outside of any pool are considered
part of cpupool0. This puts us at risk of crash when those
same pCPUs are added to another pool and something
different than the idle domain is found to be running
on them.
Note that, even if we prevent the above to happen (which
is the purpose of this patch), this is still pretty bad,
in fact, when we remove a pCPU from Pool-0:
- in Credit1, as we do *not* update prv->ncpus and
prv->credit, which means we're considering the wrong
total credits when doing accounting;
- in Credit2, the pCPU remains part of one runqueue,
and is hence at least considered during load balancing,
even if no vCPU should really run there.
In Credit1, this "only" causes skewed accounting and
no crashes because there is a lot of `cpumask_and`ing
going on with the cpumask of the domains' cpupool
(which, BTW, comes at a price).
A quick and not to involved (and easily backportable)
solution for Credit2, is to do exactly the same.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com Acked-by: George Dunlap <george.dunlap@citrix.com>
Dario Faggioli [Tue, 17 Jan 2017 17:26:38 +0000 (18:26 +0100)]
xen: credit2: use the correct scratch cpumask.
In fact, there is one scratch mask per each CPU. When
you use the one of a CPU, it must be true that:
- the CPU belongs to your cpupool and scheduler,
- you own the runqueue lock (the one you take via
{v,p}cpu_schedule_lock()) for that CPU.
This was not the case within the following functions:
get_fallback_cpu(), csched2_cpu_pick(): as we can't be
sure we either are on, or hold the lock for, the CPU
that is in the vCPU's 'v->processor'.
migrate(): it's ok, when called from balance_load(),
because that comes from csched2_schedule(), which takes
the runqueue lock of the CPU where it executes. But it is
not ok when we come from csched2_vcpu_migrate(), which
can be called from other places.
The fix is to explicitly use the scratch space of the
CPUs for which we know we hold the runqueue lock.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reported-by: Jan Beulich <JBeulich@suse.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Jan Beulich [Tue, 24 Jan 2017 16:22:03 +0000 (16:22 +0000)]
x86emul/test: don't use *_len symbols
... as they don't work as intended with -fPIC.
I did prefer them over *_end ones at the time because older gcc would
cause .L* symbols to be public, due to issuing .globl for all
referenced externals. And labels at the end of instructions collide
with the ones at the start of the next instruction, making disassembly
harder to grok. Luckily recent gcc no longer issues those .globl
directives, and hence .L* labels, staying local by default, no longer
get in the way.
Reported-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Wei Liu <wei.liu2@citrix.com>
Joao Martins [Tue, 24 Jan 2017 11:37:36 +0000 (12:37 +0100)]
x86/hvm: do not set msr_tsc_adjust on hvm_set_guest_tsc_fixed
Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest")
implemented TSC_ADJUST MSR for hvm guests. Though while booting
an HVM guest the boot CPU would have a value set with delta_tsc -
guest tsc while secondary CPUS would have 0. For example one can
observe:
$ xen-hvmctx 17 | grep tsc_adjust
TSC_ADJUST: tsc_adjust ff9377dfef47fe66
TSC_ADJUST: tsc_adjust 0
TSC_ADJUST: tsc_adjust 0
TSC_ADJUST: tsc_adjust 0
Upcoming Linux 4.10 now validates whether this MSR is correct and
adjusts them accordingly under the following conditions: values of < 0
(our case for CPU 0) or != 0 or values > 7FFFFFFF. In this conditions it
will force set to 0 and for the CPUs that the value doesn't match all
together. If this msr is not correct we would see messages such as:
And on HVM guests supporting TSC_ADJUST (requiring at least Haswell
Intel) it won't boot.
Our current vCPU 0 values are incorrect and according to Intel SDM which on
section "Time-Stamp Counter Adjustment" states that "On RESET, the value
of the IA32_TSC_ADJUST MSR is 0." hence we should set it 0 and be
consistent across multiple vCPUs. Perhaps this MSR should be only
changed by the guest which already happens through
hvm_set_guest_tsc_adjust(..) routines (see below). After this patch
guests running Linux 4.10 will see a valid IA32_TSC_ADJUST msr of value
0 for all CPUs and are able to boot.
On the same section of the spec ("Time-Stamp Counter Adjustment") it is
also stated:
"If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR
adds (or subtracts) value X from the TSC, the logical processor also
adds (or subtracts) value X from the IA32_TSC_ADJUST MSR.
Unlike the TSC, the value of the IA32_TSC_ADJUST MSR changes only in
response to WRMSR (either to the MSR itself, or to the
IA32_TIME_STAMP_COUNTER MSR). Its value does not otherwise change as
time elapses. Software seeking to adjust the TSC can do so by using
WRMSR to write the same value to the IA32_TSC_ADJUST MSR on each logical
processor."
This suggests these MSRs values should only be changed through guest i.e.
throught write intercept msrs. We keep IA32_TSC MSR logic such that writes
accomodate adjustments to TSC_ADJUST, hence no functional change in the
msr_tsc_adjust for IA32_TSC msr. Though, we do that in a separate routine
namely hvm_set_guest_tsc_msr instead of through hvm_set_guest_tsc(...).
Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 24 Jan 2017 11:36:55 +0000 (12:36 +0100)]
x86/HVM: make hvm_set_guest_tsc*() static
Other than hvm_set_guest_tsc(), neither needs to be exposed. And
hvm_get_guest_tsc_adjust() is pretty pointless as a seperate function
altogether, let alone a non-static one.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 24 Jan 2017 11:36:30 +0000 (12:36 +0100)]
x86/PVH: only set accessed/busy bits for present segments
Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
little too far: We must not do such adjustments for non-present segments.
Reported-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Tested-by: Roger Pau Monné <roger.pau@citrix.com>
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces the struct hvm_pi_ops in the struct hvm_domain to hold them.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Mon, 9 Jan 2017 13:42:02 +0000 (13:42 +0000)]
x86/hvm: Conditionally leave CPUID Faulting active in HVM context
If the hardware supports faulting, and the guest has chosen to use it, leave
faulting active in HVM context.
It is more efficient to have hardware convert CPUID to a #GP fault (which we
don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Wed, 18 Jan 2017 18:10:41 +0000 (18:10 +0000)]
x86/cpuid: Hide VT-x/SVM from HVM-based control domains
The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
mask, but nothing thus far has prevented the features being visible in
HVM-based control domains (where there is no toolstack decision to hide the
features).
As a side effect of calling nestedhvm_enabled() earlier during domain
creation, it needs to cope with the params[] array not having been allocated.
Reported-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 20 Jan 2017 15:34:54 +0000 (15:34 +0000)]
x86/emul: Fix clang build following BMI1/BMI2/TBM instruction support
Travis reports that Clang objects to integer truncation during assignments to
a bitfield:
./x86_emulate/x86_emulate.c:6150:19: error: implicit truncation from 'int'
to bitfield changes value from -1 to 15 [-Werror,-Wbitfield-constant-conversion]
pxop->reg = ~0; /* rAX */
^ ~~
Use 0xf instead.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
projects / xen.git / log