Wei Liu [Thu, 23 Feb 2017 16:46:45 +0000 (16:46 +0000)]
xen-access: request compat devicemodel API
xc_hvm_inject_trap is moved to the new libdevicemodel. Request the
compat layer from libxenctrl for now to make xen-access build again.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
In Python3 'long' type have been merged into 'int', '1L' syntax is no
longer valid. Assign 'int' type to a 'long' variable in python3, so
'long(1)' will give correct result in both python2 and python3.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
In Python3, PyTypeObject looks slightly different, and also module
initialization is different. Instead of Py_InitModule, PyModule_Create
should be called on already defined PyModuleDef structure. And then
initialization function should return that module.
Additionally initialization function should be named PyInit_<name>,
instead of init<name>.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
In Python2 PyBytes is the same as PyString, but in Python3 PyString is
gone and 'str' is really PyUnicode in C-API.
When handling arbitrary data, use PyBytes - which is the right thing to
do in Python3, and pose no API change in Python2. When handling
xenstore paths and transaction ids, which have well defined format, use
PyUnicode - to ease API usage - no need to prefix all xenstore paths
with 'b' when migrating scripts to Python3.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Paul Durrant [Fri, 10 Feb 2017 14:34:15 +0000 (14:34 +0000)]
tools/libxendevicemodel: add a call to restrict the handle
My recent patch [1] to the Linux privcmd module introduced a mechanism
to restrict an open file handle to subsequently only accept operations for
a specified domain.
This patch extends the libxendevicemodel API and make use of the
mechanism in the Linux-specific code to restrict operations on the
interface handle.
Paul Durrant [Wed, 15 Feb 2017 14:44:16 +0000 (14:44 +0000)]
tools/libxendevicemodel: extract functions and add a compat layer
This patch extracts all functions resulting in a dm_op hypercall from
libxenctrl and moves them into libxendevicemodel. It also adds a compat
layer into libxenctrl, which can be selected by defining
XC_WANT_COMPAT_DEVICEMODEL_API to 1 before including xenctrl.h.
With this patch the core of libxendevicemodel still uses libxencall to
issue the dm_op hypercalls, but this is done by calling through code that
can be modified on a per-OS basis. A subsequent patch will add a Linux-
specific variant.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Wei Liu <wei.liu2@citrix.com>
Paul Durrant [Wed, 15 Feb 2017 13:54:25 +0000 (13:54 +0000)]
tools/libxendevicemodel: introduce the new library
The new xendevicemodel library is intended to be used by all Xen device
models such that the only hypercall that use will be the dm_op hypercall
added by commit 524a98c2.
This patch adds the boilerplate for the new library, with only open() and
close() entry points, and calls to those from libxenctrl in preparation
for the compat layer added by a subsequent patch.
[ Also: update MINIOS_UPSTREAM_REVISION and QEMU_TRADITIONAL_REVISION
to the commits with the corresponding changes to those other trees
- Ian Jackson ]
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Andrew Cooper [Wed, 18 Jan 2017 15:05:24 +0000 (15:05 +0000)]
x86/mm: Swap mfn_valid() to use mfn_t
Replace one opencoded mfn_eq() and some coding style issues on altered lines.
Swap __mfn_valid() to being bool, although it can't be updated to take mfn_t
because of include dependencies.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tim Deegan <tim@xen.org> Acked-by: Julien Grall <julien.grall@arm.com>
Daniel Kiper [Wed, 22 Feb 2017 13:38:06 +0000 (14:38 +0100)]
efi: create new early memory allocator
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:
1) We could use native EFI allocation functions (e.g. AllocatePool()
or AllocatePages()) to get memory chunk. However, later (somewhere
in __start_xen()) we must copy its contents to safe place or reserve
it in e820 memory map and map it in Xen virtual address space. This
means that the code referring to Xen command line, loaded modules and
EFI memory map, mostly in __start_xen(), will be further complicated
and diverge from legacy BIOS cases. Additionally, both former things
have to be placed below 4 GiB because their addresses are stored in
multiboot_info_t structure which has 32-bit relevant members.
2) We may allocate memory area statically somewhere in Xen code which
could be used as memory pool for early dynamic allocations. Looks
quite simple. Additionally, it would not depend on EFI at all and
could be used on legacy BIOS platforms if we need it. However, we
must carefully choose size of this pool. We do not want increase Xen
binary size too much and waste too much memory but also we must fit
at least memory map on x86 EFI platforms. As I saw on small machine,
e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
So, it means that we need more than 8 KiB for EFI memory map only.
Additionally, if we use this memory pool for Xen and modules command
line storage (it would be used when xen.efi is executed as EFI application)
then we should add, I think, about 1 KiB. In this case, to be on safe
side, we should assume at least 64 KiB pool for early memory allocations.
Which is about 4 times of our earlier calculations. However, during
discussion on Xen-devel Jan Beulich suggested that just in case we should
use 1 MiB memory pool like it is in original place_string() implementation.
So, let's use 1 MiB as it was proposed. If we think that we should not
waste unallocated memory in the pool on running system then we can mark
this region as __initdata and move all required data to dynamically
allocated places somewhere in __start_xen().
2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or .init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.
Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().
New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Tested-by: Doug Goldstein <cardoe@cardoe.com>
Daniel Kiper [Wed, 22 Feb 2017 13:36:56 +0000 (14:36 +0100)]
efi: build xen.gz with EFI code
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Daniel Kiper [Wed, 22 Feb 2017 13:35:05 +0000 (14:35 +0100)]
x86: add multiboot2 protocol support
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Doug Goldstein <cardoe@cardoe.com>
Jan Beulich [Wed, 22 Feb 2017 11:36:36 +0000 (12:36 +0100)]
x86/VMX: sanitize VM86 TSS handling
The present way of setting this up is flawed: Leaving the I/O bitmap
pointer at zero means that the interrupt redirection bitmap lives
outside (ahead of) the allocated space of the TSS. Similarly setting a
TSS limit of 255 when only 128 bytes get allocated means that 128 extra
bytes may be accessed by the CPU during I/O port access processing.
Introduce a new HVM param to set the allocated size of the TSS, and
have the hypervisor actually take care of setting namely the I/O bitmap
pointer. Both this and the segment limit now take the allocated size
into account.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tim Deegan <tim@xen.org> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Wed, 2 Nov 2016 15:50:23 +0000 (15:50 +0000)]
x86/emul: Support CPUID faulting via a speculative MSR read
This removes the need for every cpuid() emulation hook to individually support
CPUID faulting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 2 Nov 2016 14:36:49 +0000 (14:36 +0000)]
x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
The current hvm_msr_{read,write}_intercept() infrastructure calls
hvm_inject_hw_exception() directly to latch a fault, and returns
X86EMUL_EXCEPTION to its caller.
This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
fault is raised behind the back of the x86 emulator.
Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Andrew Cooper [Sun, 18 Dec 2016 14:56:28 +0000 (14:56 +0000)]
x86/vmx: Drop vmx_msr_state infrastructure
To avoid leaking host MSR state into guests, guest LSTAR, STAR and
SYSCALL_MASK state is unconditionally loaded when switching into guest
context.
Attempting to dirty-track the state is pointless; host state is always
restoring upon exit from guest context, meaning that guest state is always
considered dirty.
Drop struct vmx_msr_state, enum VMX_INDEX_MSR_* and msr_index[]. The guests
MSR values are stored plainly in arch_vmx_struct, in the same way as shadow_gs
and cstar are. vmx_restore_guest_msrs() and long_mode_do_msr_write() ensure
that the hardware MSR values are always up-to-date.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Sun, 18 Dec 2016 14:56:28 +0000 (14:56 +0000)]
x86/vmx: Remove vmx_save_host_msrs() and host_msr_state
A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
moving in and out of HVM vcpu context. Two of these values are compile time
constants, and the third is directly available in an existing per-cpu
variable.
There is no need to save host state in vmx_cpu_up() into a different per-cpu
structure, so drop all the infrastructure. vmx_restore_host_msrs() is
simplified to 3 plain WRMSR instructions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Sun, 18 Dec 2016 14:56:28 +0000 (14:56 +0000)]
x86/setup: Intoduce XEN_MSR_STAR
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Sun, 18 Dec 2016 14:20:49 +0000 (14:20 +0000)]
x86/vmx: Don't leak host syscall MSR state into HVM guests
hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
restored when switching into guest context. It should never have been part of
the migration state to start with, and Xen must not make any decisions based
on the value seen during restore.
Identify it as obsolete in the header files, consistently save it as zero and
ignore it on restore.
The MSRs must be considered dirty during VMCS creation to cause the proper
defaults of 0 to be visible to the guest.
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 [Mon, 4 Jul 2016 08:40:34 +0000 (09:40 +0100)]
x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
lower than the real maxphysaddr, to avoid overflowing the superpage shadow
backpointer.
However, plenty of hardware has a physical address width less that 44 bits,
and the code added in shadow_domain_init() is a straight assignment. This
causes gfn_bits to be increased beyond the physical address width on most
Intel consumer hardware (typically a width of 39, which is the number reported
to the guest via CPUID).
If the guest intentionally creates a PTE referencing a physical address
between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
address. However, the shadow code accepts the PTE, shadows it, and the
virtual address works normally.
Introduce paging_max_paddr_bits() to calculate the largest guest physical
address supportable by the paging infrastructure, and update
recalculate_cpuid_policy() to take this into account when clamping the guests
cpuid_policy to reality.
There is an existing gfn_valid() in guest_pt.h but it is unused in the
codebase. Repurpose it to perform a guest-specific maxphysaddr check, which
replaces the users of gfn_bits.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Tim Deegan <tim@xen.org>
Norbert Manthey [Fri, 17 Feb 2017 10:47:46 +0000 (11:47 +0100)]
lowmemd: fix comparison in cleanup
The variable virq_port of type uint32_t was compared to being greater than
-1. This check always results in false for unsigned data types, resulting
in never cleaning up the memory. Furthermore, the initialization with a
negative variable for an unsigned type has been fixed.
Signed-off-by: Norbert Manthey <nmanthey@amazon.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Mon, 20 Feb 2017 16:53:27 +0000 (16:53 +0000)]
libxc: don't pass uninitialized data to do_dm_op()
do_dm_op() expects (void *, size_t) pairs, but with nr being uint32_t
the type of the expression of xc_hvm_track_dirty_vram()'s last argument
to the function is only a 32 bits one. Neither C nor the ABI require
the compiler to promote the type beyond int.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Fri, 17 Feb 2017 17:40:12 +0000 (12:40 -0500)]
libxc/x86: PV guests should see leaf 0xa on Intel
PV guests support VPMU and therefore leaf 0xa can be exposed
to them.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monné [Fri, 17 Feb 2017 15:10:28 +0000 (16:10 +0100)]
build: enable no-parentheses in clang
And fix the following errors reported:
traps.c:2014:25: error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
~~~~~^~~~~~~~~~~~~~
traps.c:2014:25: note: remove extraneous parentheses around the comparison to silence this warning
else if ( (port == RTC_PORT(0)) )
~ ^ ~
traps.c:2014:25: note: use '=' to turn this equality comparison into an assignment
else if ( (port == RTC_PORT(0)) )
^~
=
traps.c:2083:25: error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
~~~~~^~~~~~~~~~~~~~
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monné [Fri, 17 Feb 2017 15:09:38 +0000 (16:09 +0100)]
build/printf: fix incorrect format specifiers
The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:
mce.c:601:18: error: data argument not used by format string [-Werror,-Wformat-extra-args]
smp_processor_id());
^
xenpm.c:102:23: error: data argument not used by format string [-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
^
libxl_internal.c:25:69: error: data argument not used by format string
[-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
[-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
func, (unsigned long)nmemb, (unsigned long)size
^
This patch contains the fixes for them and enables -Wformat for clang.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monné [Fri, 17 Feb 2017 15:08:37 +0000 (16:08 +0100)]
x86/vmx: fix compilation after 997382
997382 introduced the following errors:
intr.c:342:46: error: address of array 'vlapic->regs->data' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
if ( vlapic && vlapic->regs->data )
~~ ~~~~~~~~~~~~~~^~~~
intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
if ( pi_desc && pi_desc->pir )
~~ ~~~~~~~~~^~~
Both of those checks are done against static arrays, which doesn't seem to make
much sense, so just remove them.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 17 Feb 2017 14:59:15 +0000 (15:59 +0100)]
console: avoid wrapping of console pointers
We particularly want/need to avoid accessing data outside (ahead of)
the ring buffer. Also latch both pointers into local variable to
avoid different steps of the calculation being done with different
values.
Reported-by: Quan Luo <a4651386@163.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Haozhong Zhang [Fri, 17 Feb 2017 14:55:47 +0000 (15:55 +0100)]
x86/mce: remove declarations of non-existing functions in mce.h
Remove declarations of functions
intel_mcheck_timer()
mce_intel_feature_init()
mce_cap_init()
x86_mcinfo_getptr()
whose definitions had been removed long time ago.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Norbert Manthey [Fri, 17 Feb 2017 14:51:37 +0000 (15:51 +0100)]
x86/mm: fix memory hotplug error cleanup
During destroying the m2p mapping, the loop variable was always incremented
by one, as the current version used a compare operator on the left hand side,
which always evaluated to true, i.e.
i += 1UL < (L2_PAGETABLE_SHIFT - 2)
The fix increments the value of the variable by the actual page size by
using the shift operator instead.
Signed-off-by: Norbert Manthey <nmanthey@amazon.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 17 Feb 2017 14:51:03 +0000 (15:51 +0100)]
x86: package up context switch hook pointers
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_tail() in the only two places invoking it, allowing the macro
to be dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Fri, 17 Feb 2017 14:49:56 +0000 (15:49 +0100)]
VMX: fix VMCS race on context-switch paths
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
For consistency use the new function also in vmx_do_resume(), to
avoid leaving an open-coded incarnation of it around.
Reported-by: Kevin Mayer <Kevin.Mayer@gdata.de> Reported-by: Anshul Makkar <anshul.makkar@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com> Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>
We don't need a lock in vgic_get_target_vcpu anymore, solving the
following lock inversion bug: the rank lock should be taken first, then
the vgic lock. However, gic_update_one_lr is called with the vgic lock
held, and it calls vgic_get_target_vcpu, which tries to obtain the rank
lock.
Jan Beulich [Thu, 16 Feb 2017 17:11:42 +0000 (18:11 +0100)]
x86emul: catch exceptions occurring in stubs
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.
Since the exception fixup table entry can't encode the address of the
faulting insn itself, attach it to the return address instead. This at
once provides a convenient place to hand the exception information
back: The return address is being overwritten by it before branching to
the recovery code.
Take the opportunity and (finally!) add symbol resolution to the
respective log messages (the new one is intentionally not being coded
that way, as it covers stub addresses only, which don't have symbols
associated).
Also take the opportunity and make search_one_extable() static again.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Tue, 14 Feb 2017 18:21:22 +0000 (18:21 +0000)]
x86/hypercall: Make the HVM hcall_64bit boolean common
HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of
the hypercall in use.
The rest of Xen deals in terms of the comat ABI or not, so rename the boolean
and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is
not wanted/needed.
Set hcall_compat uniformly for PV guests as well as HVM guests. This removes
the remaining piece of guest-type-specific knowledge from
hypercall_create_continuation(), allowing it to operate only in terms of the
hypercall ABI in use.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 14 Feb 2017 17:02:04 +0000 (17:02 +0000)]
x86/hypercall: Make the HVM hcall_preempted boolean common
HVM guests currently make use of arch.hvm_vcpu.hcall_preempted to track
hypercall preemption in struct vcpu. Move this boolean to being common at the
top level of struct vcpu, which will allow it to be reused elsewhere.
Alter the PV preemption logic to use this boolean. This simplifies the code
by removing guest-type-specific knowledge, and removes the risk of accidently
skipping backwards or forwards multiple times and corrupting %rip.
In pv_hypercall() the old_rip bodge can be removed, and parameter clobbering
can happen based on a more obvious condition.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 15 Feb 2017 18:04:58 +0000 (18:04 +0000)]
xen/include: Include xen/kconfig.h automatically
generated/autoconf.h is already included automatically so CONFIG_* defines are
available. However, the companion macros such as IS_ENABLED() are not
included.
Include them uniformly everywhere.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com>
George Dunlap [Wed, 15 Feb 2017 17:08:11 +0000 (17:08 +0000)]
tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY
Callers to libxl_cpupool_create() can either request a specific pool
id, or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).
Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
instead. Still accept '0' as meaning "ANY" for backwards
compatibility.
Signed-off-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: removed two trailing spaces ] Signed-off-by: Wei Liu <wei.liu2@citrix.com>
George Dunlap [Wed, 15 Feb 2017 17:08:10 +0000 (17:08 +0000)]
tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY
Callers to xc_cpupool_create() can either request a specific pool id,
or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).
Introduce a constant, XC_CPUPOOL_POOLID_ANY, to indicate this instead.
Have it be the default for the python bindings.
Manually translate it, even though it's the same underlying value,
because we don't yet have a relaible way of enforcing that these
values are the same.
Signed-off-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Wed, 15 Feb 2017 11:11:12 +0000 (12:11 +0100)]
libxl: correct xenstore entry for empty cdrom
Specifying an empty cdrom device will result in a Xenstore entry
params = aio:(null)
as the physical device path isn't existing. This lets a domain booted
via OVMF hang as OVMF is checking for "aio:" only in order to detect
the empty cdrom case.
Use an empty string for the physical device path in this case. As a
cdrom device for HVM is always backed by qdisk we only need to cover this
backend.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Julien Grall [Fri, 3 Feb 2017 19:18:45 +0000 (19:18 +0000)]
xen/arm: acpi: Handle correctly detection of GICv2 on GICv3
When the GICv3 is not GICv2 compatible, the associated field in the MADT
will be zeroed. However, the rest of the code expects the variable to
be set to INVALID_PADDR.
This will result to false detection of GICv2 and give I/O access to page
0 for the hardware domain.
Thankfully, it will fail because the size of GICV has not been set.
Fix the detection by converting 0 to INVALID_PADDR for the GICC and
GICV base. At the same time only set the size of each region when the
base address is not 0.
Julien Grall [Fri, 3 Feb 2017 19:21:13 +0000 (19:21 +0000)]
xen/arm: Remove the makefile target xen.axf
Since commit 4557c22 "xen: arm: rewrite start of day page table and cpu
bring up", Xen requires to be launched in NS HYP/EL2.
xen.axf is generated in order to directly boot Xen on ARM models (e.g
Foundation). However they usually start in secure mode, which mean Xen
cannot boot.
The way forward to boot Xen on models is using either EFI or
bootwrapper [1].
Andrew Cooper [Thu, 9 Feb 2017 17:08:44 +0000 (17:08 +0000)]
x86/asm: Use ASM_FLAG_OUT() to simplify atomic and bitop stubs
bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
to a new asm/compiler.h to compensate.
While making changes, switch bool_t to bool and use named asm parameters.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
George Dunlap [Wed, 15 Feb 2017 17:13:22 +0000 (17:13 +0000)]
xen/p2m: Fix p2m_flush_table for non-nested cases
Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed. Unfortunately
in the process, it added a filter to p2m_flush_table() function so
that the p2m would only be flushed if it was being used as a nested
p2m. This meant that the p2m was not being flushed at all for altp2m
callers.
Only check np2m_base if p2m_class for nested p2m's.
NB that this is not a security issue: The only time this codepath is
called is in cases where either nestedp2m or altp2m is enabled, and
neither of them are in security support.
Reported-by: Matt Leinhos <matt@starlab.io> Signed-off-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Tim Deegan <tim@xen.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Dario Faggioli [Wed, 15 Feb 2017 15:47:29 +0000 (15:47 +0000)]
xen: sched: harmonize debug dump output among schedulers.
Information we currently print for idle vCPUs is
rather useless. Credit2 already stopped showing that,
do the same for Credit and RTDS.
Also, define a new CPU status dump hook, which is
not defined by those schedulers which already dump
such info in other ways (e.g., Credit2, which does
that while dumping runqueue information).
This also means that, still in Credit2, we can keep
the runqueue and pCPU info closer together.
That way we have one person who can: a) poke other maintainers
or pull them in with new drivers are introduced, b) we have
one maintainer who can shepherd the patches along instead of
depending on the REST maintainers which may be busy with
other responsibilities.
Acked-by: Ian Jackson <ian.jackson@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There is a possible scenario when (d)->need_iommu remains unset
during guest domain execution. For example, when no devices
were assigned to it. Taking into account that teardown callback
is not called when (d)->need_iommu is unset we might have unreleased
resourses after destroying domain.
So, always call teardown callback to roll back actions
that were performed in init callback.
This is XSA-207.
Signed-off-by: Oleksandr Tyshchenko <olekstysh@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Tested-by: Jan Beulich <jbeulich@suse.com> Tested-by: Julien Grall <julien.grall@arm.com>
Andrew Cooper [Mon, 13 Feb 2017 11:49:30 +0000 (11:49 +0000)]
x86/hvm: Improve physdev_op hypercall dispatching
hvm_physdev_op() and hvm_physdev_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into a single hvm_physdev_op() and dispatch to
{do,compat}_physdev_op() based on the hcall_64bit setting.
This also fixes an inconsistency where 64bit PVH hardware domains were
permitted access to extra physdev ops, but 32bit domains weren't.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
but there is no need to have two functions instantiated at the end of
different function pointers.
Combine the two into a single hvm_grant_table_op() (folding
grant_table_op_is_allowed() into is now-single caller) and dispatch to
{do,compat}_grant_table_op() based on the hcall_64bit setting.
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 [Mon, 13 Feb 2017 11:49:24 +0000 (11:49 +0000)]
x86/hvm: Improve memory_op hypercall dispatching
hvm_memory_op() and hvm_memory_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into single hvm_memory_op() which dispatches to
{do,compat}_memory_op() based on the hcall_64bit setting.
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 [Fri, 3 Feb 2017 16:21:22 +0000 (16:21 +0000)]
x86/hvm: Rework HVM_HCALL_invalidate handling
Sending an invalidation to the device model is an internal detail of
completing the hypercall; callers should not need to be responsible for it.
Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
appropriate.
This makes the function boolean in nature, although the existing
HVM_HCALL_{completed,preempted} constants are kept to aid code clarity. While
updating the return type, drop _do from the name, as it is redundant.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
projects / xen.git / log