x86/viridian: freeze time reference counter when domain is paused

In XenServer system test it has become apparent that versions of Windows
that make use of the time reference counter enlightenment cannot cope with
large jumps forward in the value read from the MSR. Specifically,
suspending a very large domain took approx. 45 minutes to complete and
when the domain was resumed it was discovered that the WMI (Windows
Management Instrumentation) service had hung.

The reason a large jump forward is seen by the guest is that, when a guest
is suspended, the guest stops running when the SCHEDOP_suspend hypercall is
made, however the MSR value essentially keeps incrementing until the
tool-stack issues DOMCTL_gethvmcontext.

This patch adds code to freeze the value of the time reference counter
on domain pause and 'thaw' it on domain unpause, but only thaw it if the
domain is not shutting down. The absolute value of the counter is then
saved in the viridian domain context record. This prevents the guest OS
from experiencing large jumps in the value of the MSR and has been shown
to reliably fix the problem with WMI.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
clean target should remove xen.efi binary

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
x86: define cmdline_cook() loader_name argument as a const

cmdline_cook() loader_name argument is not changed so
define it as a const.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
x86/hvm: further restrict access to x2apic MSRs

The x2apic specification reserves the entire MSR range 0x800-0xbff, while only
the first 0x3f MSRs have defined purposes.  All reserved MSRs in this region
are architecturally required to raise #GP faults upon access.

Xen used to pass this entire range to hvm_x2apic_msr_{read,write}(), but the
range was restricted somewhat by XSA-108 (c/s 61fdda7ac) to prevent guests
being able to read pages adjacent to the domheap page backing the vlapic->regs
array.

While removing the vulnerability, a side effect of XSA-108 was that the MSR
range 0x900-0xbff fell through the switch statement and ends up reading the
hosts x2apic range. This behaviour is a problem in general, but specifically
it turns out that MSRs 0xa00-0xa02 are implemented (but undocumented) on
certain SandyBridge and IvyBridge systems.

Experimentally, no operating system in XenServer's test suite (including all
versions of Windows currently supported by Microsoft) ever peek at these MSRs,
even on hosts where some of them are implemented.

This patch undoes the fix for XSA-108 (c/s 61fdda7ac), returning the primary
bounds check to the entire specified range.  hvm_x2apic_msr_write() was always
safe, as it is whitelist based.  hvm_x2apic_msr_read() changes to a whitelist
approach, which avoids the vulnerability, and provides a more architecturally
accurate emulation of the reserved MSRs (which would previously read as 0
rather than fault).

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
x86/setup: correct register clobbers for the asm statement when resyncing the stack

When resyncing the stack, the asm statement does not identify %rsi, %rdi and
%rcx as clobbered by the 'rep movsq'.

Luckily, there are no functional problems in the generated code.  GCC decides
not to save any of them before calling boostrap_map(), which clobbers them.

Correct the clobbers, by listing them as earlyclobber discarded outputs.

Reported-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Daniel Kiper <daniel.kiper@oracle.com>
fix listing of vcpus when domains lacking any vcpus exist

On a system which looks like this:

[root@st04 ~]# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   752     4     r-----   46699.3
(null)                                       1     0     0     --p---       0.0
(null)                                       2     0     0     --p---       0.0
(null)                                       3     0     0     --p---       0.0
badger                                      25     0     1     --p---       0.0

`xl vcpu-list` failes as so:

[root@st04 ~]# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-   12171.0  all
Domain-0                             0     1    1   -b-   11779.6  all
Domain-0                             0     2    2   -b-   11599.0  all
Domain-0                             0     3    3   r--   11007.0  all
libxl: critical: libxl__calloc: libxl: FATAL ERROR: memory allocation failure (libxl__calloc, 4294935299 x 40)
: Cannot allocate memory
libxl: FATAL ERROR: memory allocation failure (libxl__calloc, 4294935299 x 40)

The root cause of this is in Xen.  getdomaininfo() has no way of expressing
"this domain has no vcpus".  Previously, info->max_vcpu_id would be returned
uninitialised in such a case.

Unfortunately, setting it to 0 as a default is not appropriate.  A max_vcpu_id
of 0 and nr_online_cpus of 0 is the valid state for a single vcpu domain which
is in the process of being destroyed.

As all components are required to add 1 to max_vcpu_id to get the number of
vcpus, an id of ~0U is not valid to be used.  Explicitly define this as an
invalid max vcpu value, and use it to express "no vcpus" in getdomaininfo()

In libxl, the issue is seen as libxl_list_vcpu() attempts to use the
uninitialised domaininfo.max_vcpu_id for memory allocation.

Check domaininfo.max_vcpu_id against the new sentinel value
XEN_INVALID_MAX_VCPU_ID, and return early.  This means that it is now valid
for libxl_list_vcpu() to return NULL for a domain which lacks any vcpus.

As part of this change, remove the pointless call to libxl_get_max_cpus(),
whose returned value is unconditionally clobbered in the for() loop.

Reported-by: Euan Harris <euan.harris@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
correct the documentation of where the Xen cpuid leaves can be found

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: fix reloc.S build dependencies

reloc.S is not rebuild if header included
in reloc.c is updated. Fix this issue.

Additionally, remove reloc.S build dependency
on head.S because anything from reloc.S does
not depend on head.S.

Add reloc.c dependency to reloc.o build rule for consistency.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: use constant in head.S instead of hardcoded value

..to access multiboot.mem_lower data.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: add memory to clobber list in reloc_mbi_struct()

Assembly inline in reloc_mbi_struct() clobbers
memory so tell compiler about that.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
EFI: fix efi_arch_allocate_mmap_buffer() to return new size

efi_arch_allocate_mmap_buffer() allocates a buffer for the EFI memory map, and
for ARM it allocates a larger buffer than requested. This is done to account
for the increase in the map size that may occur when the allocation is made.
The previous code allocated a larger buffer, but did not adjust the size to
match.  This caused the later call to GetMemoryMap() to fail with a
BUFFER_TOO_SMALL error, since the original, smaller size was used.  This patch
changes the argument to efi_arch_allocate_mmap_buffer() to be a pointer to
UINTN, and the ARM version updates the size on a successful allocation.
The x86 version uses a different allocation method, so only the function
argument type is changed.
Also add decode of the BUFFER_TOO_SMALL error code to PrintErrMesg().

Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com> [ARM]
Acked-by: Jan Beulich <jbeulich@suse.com> [non-ARM]
docs: EFI configuration file must be ASCII type

Currently Xen can only read the configuration file if it is in ASCII
format. If it is in CHAR16 or CHAR8 it will choke. One way to verify
this is to use 'file':

xen.cfg:        ASCII text
xen-char16.cfg: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators

The latter is no good.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
introduce gnttab_max_frames and gnttab_max_maptrack_frames command line options

Introduce gnttab_max_maptrack_frames: a new Xen command line option to
specify the max number of maptrack frames per domain.
Deprecate the old gnttab_max_nr_frames and introduce gnttab_max_frames
instead, that doesn't affect the maptrack. Keep gnttab_max_nr_frames for
compatibility.

Rename internally max_nr_grant_frames to max_grant_frames to avoid
confusions.

Introduce DEFAULT_MAX_MAPTRACK_FRAMES, that is completely independent
from max_nr_grant_frames.

Remove MAX_MAPTRACK_TO_GRANTS_RATIO that is now only used in one place
for compatibility.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
arm: rename *_xen_dcache_* operations to *_dcache_*

Given that we are in Xen, it is obvious that these are Xen flushes.
Also the correspondent x86 functions are going to be named without
_xen_, so remove it here for consistency.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
arm: return int from *_dcache_va_range

These functions cannot really fail on ARM, but their x86 equivalents can
(-EOPNOTSUPP). Change the prototype to return int.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
arm: introduce invalidate_dcache_va_range

Take care of handling non-cacheline aligned addresses and sizes.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86: introduce more cache maintenance operations

Move the existing flush_page_to_ram flushtlb.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
introduce GNTTABOP_cache_flush

Introduce a new hypercall to perform cache maintenance operation on
behalf of the guest. The argument is a machine address and a size. The
implementation checks that the memory range is owned by the guest or the
guest has been granted access to it by another domain.

Introduce grant_map_exists: an internal grant table function to check
whether an mfn has been granted to a given domain on a target grant
table. Check hypercall_preempt_check() every 4096 iterations in the
implementation of grant_map_exists.
Use the top 20 bits of the GNTTABOP cmd encoding to save the last ref
across the hypercall continuation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Revert "xen/arm: introduce XENFEAT_grant_map_identity"

Revert commit id 8d09ef6906ca0a9957e21334ad2c3eed626abe63.
Just keep the definition of XENFEAT_grant_map_identity.

XENFEAT_grant_map_identity is superseeded by GNTTABOP_cache_flush.  As
XENFEAT_grant_map_identity causes additional tlb flushes, it is best to
remove the feature entirely now.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Revert "xen: introduce arch_grant_(un)map_page_identity"

This reverts commit e25a5f4d8cf3b55718048abdd21c7d0de64ae54c.

With the removal of XENFEAT_grant_map_identity, this commit is not
needed anymore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>