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>
x86: hvm: Allow configuration of the size of the mmio_hole.

If you add enough PCI devices then all mmio may not fit below 4G
which may not be the layout the user wanted. This allows you to
increase the below 4G address space that PCI devices can use and
therefore in more cases not have any mmio that is above 4G.

There are real PCI cards that do not support mmio over 4G, so if you
want to emulate them precisely, you may also need to increase the
space below 4G for them. There are drivers for these cards that also
do not work if they have their mmio space mapped above 4G.

This allows growing the MMIO hole to the size needed.

This may help with using pci passthru and HVM.

In the tools this is named mmio_hole_memkb.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fixed build error in xl_cmdimpl.c with s/%PRIu64/%ld/.
         Reworded title ]
README: remove requirement for udev

There is no requirement for udev during package build. It may be
required at runtime even with libxl with run_hotplug_scripts=yes
in xl.conf.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
README: mention git repos at xen.org

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools/libxl: Fix libxl_list_vcpu() following c/s 93e52d52

My reasoning regarding nr_cpus_out was wrong, as I had confused nr_cpus_out
with nr_vcpus_out.

Dario pointed this out, but the patch (having gained appropriate acks) got
committed before I could post a correction.

Noticed-by: Dario Faggioli <dario.faggioli@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>