x86: Remove USER_MAPPINGS_ARE_GLOBAL definition

It has been unconditionally enabled for 64bit Xen builds since 2006
  c/s 6f562e72 "[XEN][X86_64] USe GLOBAL bit to build user mappings."

Adjust the order of definitions in x86_64/page.h to put the bit definitions
for pte flags together.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
avoid crash when doing shutdown with active cpupools

When shutting down the machine while there are cpus in a cpupool other than
Pool-0 a crash is triggered due to cpupool handling rejecting offlining the
non-boot cpus in other cpupools.

It is easy to detect this case and allow offlining those cpus.

Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Stefan Bader <stefan.bader@canonical.com>
x86: fix pvh dom0 boot after dab11417d

Changeset dab11417d
"x86/HVM: consolidate and sanitize CR4 guest reserved bit determination"

did not take into account the fact that dom0 does not have a cpuid policy.  As
a result, PVH dom0s would be given unexpected #GP faults on boot.

In addition to the restore case (where the toolstack has not had time to load
a cpuid policy), unconditionally exempt the hardware domain from needing a
policy.

Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com>
x86/mem_event: fix regression affecting CR0 memory events

This is a patch repairing a regression in code previously functional in 4.1.x.
It appears that, during some refactoring work, call to hvm_memory_event_cr0 was lost.

This function was originally called in mov_to_cr() of vmx.c, but the commit
http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the
original code into generic functions up a level in hvm.c, dropping the call
in the process.

The same issue affected the CR3 and CR4 events, which were fixed in patch
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/7ab899e46347.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/mem_event: validate the response vcpu_id before acting on it

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
x86/mem_event: prevent underflow of vcpu pause counts

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Tested-by: Aravindh Puthiyaparambil <aravindp@cisco.com>
x86/kexec: fix kexec on systems which boot in x2apic mode

Moving straight from fully disabled to x2apic mode is an illegal state
transition, and causes an unconditional #GP fault.  Bounce through xapic mode
to avoid the fault.

In addition, avoid bouncing through the various apic modes if the mode is
already correct.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86, amd_ucode: support multiple container files appended together

This patch adds support for parsing through multiple AMD container
binaries concatenated together. It is a feature already present in Linux.
Link to linux patch:
http://lkml.kernel.org/r/1370463236-2115-3-git-send-email-jacob.shin@amd.com

Other changes introduced:
 - Define HDR_SIZE's explicitly for code clarity.
 - Minor cleanup: Remove extra casts in that are used in
   install_equiv_cpu_table()

Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
document IOMMU related command line options

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
libxc: disable valgrind integration when building for minios

The stubdom build system incorrectly picks up on the hosts
installation of Valgrind, which cannot work in a stubdom environment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Simon Martin <furryfuttock@gmail.com>
Reviewed-by: Andrew Cooper<andrew.cooper3@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
[ ijc -- s/define/defined/ ]
xen: arm: correct whitespace/comments and use #defines in head.S

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Handle 4K aligned hypervisor load address.

Currently the boot page tables map Xen at XEN_VIRT_START using a 2MB section
mapping. This means that the bootloader must load Xen at a 2MB aligned address.
Unfortunately this is not the case with UEFI on the Juno platform where Xen
fails to boot. Furthermore the Linux boot protocol (which Xen claims to adhere
to) does not have this restriction, therefore this is our bug and not the
bootloader's.

Fix this by adding third level pagetables to the boot time pagetables, allowing
us to map a Xen which is aligned only to a 4K boundary. This only affects the
boot time page tables since Xen will later relocate itself to a 2MB aligned
address. Strictly speaking the non-boot processors could make use of this and
use a section mapping, but it is simpler if all processors follow the same boot
path.

Strictly speaking the Linux boot protocol doesn't even require 4K alignment
(and apparently Linux can cope with this), but so far all bootloaders appear to
provide it, so support for this is left for another day.

In order to use LPAE_ENTRIES in head.S we need to define it in an asm friendly
way.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
[ ijc -- properly format message "- FOO -\r\n" ]
xen: arm: Do not use level 0 section mappings in boot page tables.

Level 0 does not support superpage mappings, meaning that systems on where Xen
is loaded above 512GB (I'm not aware of any such systems) the 1:1 mapping on
the boot page tables is invalid.

In order to avoid this issue we need an additional first level page table
mapped by the appropriate L0 slot and containing a 1:1 superpage mapping.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: avoid unnecessary additional mappings in boot page tables.

If the identity map is created at one level then avoid creating
entries further down the boot page tables, since these will be aliases at
strange virtual address.

For example consider an arm32 system (for simplicity) with Xen loaded at
address 0x40402000. As a virtual address this corresponds to walking offsets 1,
2 and 2 at the first, second and third levels respectively.

When creating the identity map we will therefore create a 1GB super mapping at
0x40000000 for the identity map, which is the one we want to use.

However when considering the second level we will see the offset 2 and create a
2MB mapping in slot 2 of boot_second. Since boot_second is mapped in slot 0 of
boot_first this corresponds to an unwanted mapping from virtual address
0x00400000 to physical address 0x40400000.

We still do not handle the case where the load address is within the 2MB range
starting just after XEN_VIRT_START. This is not a regression but this patch
tries to provide a more useful diagnostic message. We do handle loading at
exactly XEN_VIRT_START.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: ensure that the boot code is <4K in size

This avoids having to deal with the 1:1 boot mapping crossing a
section or page boundary.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Correctly use GLOBAL/ENTRY in head.S, avoid .global

Use ENTRY() for function entry points since it ensures correct
alignment where GLOBAL() doesn't. The exception is the initial start
label which must be at offset 0, so just use GLOBAL() to avoid the
possibility of realignment.

Since everything happens to already be aligned there should be no
difference to the actual binary. objdump agrees.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Only lookup kernel/initrd bootmodule once while building dom0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: don't release modules which aren't in RAM into the heap

They might be in e.g. flash or something but more likely they could
be in a bank of RAM which we aren't handling or in RAM which the
bootloader hasn't told us about for some reason.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Fu Wei <fu.wei@linaro.org>
Cc: Roy Franz <roy.franz@linaro.org>
mini-os: tpm: fix array access in locality_enabled

gcc-4.3 fails to prove that array indices will remain positive. Add a
hint for the compiler and check the index value before using it.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
mini-os: tpm: remove usage of inline keyword

Compilation fails with gcc-4.3:

tpmback.c: In function 'tpmback_resp':
tpmback.c:148: error: inlining failed in call to 'tpmdev_check_req': call is unlikely and code size would grow
tpmback.c:165: error: called from here
tpmback.c: In function 'new_tpmif':
tpmback.c:384: error: inlining failed in call to '__init_tpmif': call is unlikely and code size would grow
tpmback.c:425: error: called from here

Adjust code to use static instead of inline, it has the same effect.
Change also tpmif_req_ready and tpmif_req_finished before they start to
cause failures.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>