docs: remove stray CONFIG_XENDs and configure option from docs.

These were added by 7dbfc2f8b054 "docs: Honour --{en, dis}able-xend when
building docs" between v1 and the (eventually committed) v2 of 9e8672f1c36d
"tools: remove xend and associated python modules" and were missed when
rebasing for v2.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
tools/hotplug: Remove network-*

From 3f2142f0b7a0d600fa8d2d06b5eacf0d52aa5bca Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 4 Apr 2014 15:00:12 +0100
Subject: [PATCH v2] tools/hotplug: Remove network-*

These are a xend-ism. Since Xen 4.1 the recommened way to configure networking
has been to use the distro facilities (e.g.
http://wiki.xen.org/wiki/HostConfiguration/Networking)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
docs: remove xend latex source

AFAICT this hasn't actually been built since 8311d176ea6ff "docs: Remove
outdated LaTex documentation".

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
build: remove Linux kernel build integration.

We haven't shipped a XenoLinux kernel for more releases than I can remember.
We held onto these because osstest was using them but this is no longer the
case.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
xen: make sure that likely and unlikely convert the expression to a boolean

According to http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
__builtin_expect has the prototype:
    long __builtin_expect (long exp, long c)

If sizeof(exp) > sizeof(long) then this will effectively mask off the top bits
of exp, meaning that the if in "if (unlikey(x))" will see the masked version,
which might be false when true was expected, likely has the same issue.

This is mostly likely to affect x86_32 and arm32 builds.  x86_32 is not
present on 4.3 onwards and a quick grep of current staging shows that all the
existing arm32  uses of both likely and unlikely already pass a boolean. I
noticed this with an as yet unposted patch which did not have this property.

Also the defintion of likely might not have had the expected affect for cases
where a true value > 1 might be passed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
tools: arm: improve placement of initial modules.

314c9815e2f5 "tools: implement initial ramdisk support for ARM." broke starting
guests with <= 128 MB ram by placing the boot modules (dtb and initrd)
immediately after the kernel in this case, running the risk of them being
overwritten. Instead place the modules at the end of RAM, as the hypervisor
does for dom0.

The hypervisor also falls back to placing things before the kernel as a last
resort before failing, so add that here too.

Tested with the Debian installer initrd and guests of 96MB, 128MB, 256MB and
1GB. All work, also tested with 64MB but the installer doesn't run with so
little RAM (but our placement of the initrd is correct).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
xen: arm: use same variables as userspace in dom0 builder place_modules()

The placement algorithm should be effectively the same and using different
variable names makes my head hurt when I try to compare.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: rework dom0 initrd and dtb placement

This now uses the same decision tree as libxc (which is much easier to test).

The main change is to explicitly handle the placement at 128MB or end of RAM
as two cases, rather than combining with MIN. The effect is the same but the
code is clearer.

Secondly the attempt to place the modules right after the kernel is removed,
since it is redundant with the case where placing them at the end of RAM ends
up abutting the kernel.

Also round the kernel size up to a 2MB boundary.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Change Xen RAS maintainer email

... since Jinsong switched to Alibaba Corp.

Signed-off-by: Liu Jinsong <jinsong.liu@alibaba-inc.com>
Change Xen POWER MANAGEMENT maintainer email

... since Jinsong switched to Alibaba Corp.

Signed-off-by: Liu Jinsong <jinsong.liu@alibaba-inc.com>
x86/EPT: force re-evaluation of memory type as necessary

The main goal here is to drop the bogus dependency of
epte_get_entry_emt() on d->arch.hvm_domain.params[HVM_PARAM_IDENT_PT].

Any change to state influencing epte_get_entry_emt()'s decision needs
to result in re-calculation. Do this by using the EPT_MISCONFIG VM
exit, storing an invalid memory type into EPT's emt field (leaving the
IOMMU, which doesn't care about memory types, unaffected).

This is being done in a hierarchical manner to keep execution time
down: Initially only the top level directory gets invalidated this way.
Upon access, the involved intermediate page table levels get cleared
back to zero, and the leaf entry gets its field properly set. For 4k
leaves all other entries in the same directory also get processed to
amortize the cost of the extra VM exit (which halved the number of
these VM exits in my testing).

This restoring can result in spurious EPT_MISCONFIG VM exits (since
two vCPU-s may access addresses involving identical page table
structures). Rather than simply returning in such cases (and risking
that such a VM exit results from a real mis-configuration, which
would then result in an endless loop rather than killing the VM), a
per-vCPU flag is being introduced indicating when such a spurious VM
exit might validly happen - if another one occurs right after VM re-
entry, the flag would generally end up being clear, causing the VM
to be killed as before on such VM exits.

Note that putting a reserved memory type value in the EPT structures
isn't formally sanctioned by the specification. Intel isn't willing to
adjust the specification to make this or a similar use of the
EPT_MISCONFIG VM exit formally possible, but they have indicated that
us using this is low risk wrt forward compatibility.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/EPT: split super pages upon mismatching memory types

... between constituent pages. To indicate such, the page order is
being passed down to the vMTRR routines, with a negative return value
(possible only on order-non-zero pages) indicating such collisions.

Some code redundancy reduction is being done to ept_set_entry() along
the way, allowing the new handling to be centralized to a single place
there.

In order to keep ept_set_entry() fast and simple, the actual splitting
is being deferred to the EPT_MISCONFIG VM exit handler.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/EPT: IOMMU snoop capability should not affect memory type selection

This capability solely makes a statement on cache coherency guarantees
by the IOMMU. It does specifically not imply any further guarantees
implied by certain memory types (cachability, ordering).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86: fix pinned cache attribute handling

- make sure UC- is only used for PAT purposes (MTRRs and hence EPT
  don't have this type)
- add order input to "get", and properly handle conflict case (forcing
  an EPT page split)
- properly detect (and refuse) overlaps during "set"
- properly use RCU constructs
- support deleting ranges through a special type input to "set"
- set ignore-PAT flag in epte_get_entry_emt() when "get" succeeds
- set "get" output to ~0 (invalid) rather than 0 (UC) on error (the
  caller shouldn't be looking at it anyway)
- move struct hvm_mem_pinned_cacheattr_range from header to C file
  (used only there)

Note that the code (before and after this change) implies the GFN
ranges passed to the hypercall to be inclusive, which is in contrast
to the sole current user in qemu (all variants). It is not clear to me
at which layer (qemu, libxc, hypervisor) this would best be fixed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/AMD: support further feature masking MSRs

Newer AMD CPUs also allow masking CPUID leaf 6 ECX and CPUID leaf 7
sub-leaf 0 EAX and EBX.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Aravind Gopalakrishnan<aravind.gopalakrishnan@amd.com>
x86/AMD: clean up pre-canned family/revision handling for CPUID masking

Make it so this is easier to extend, and move the parsing code/data
into .init.* sections.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Aravind Gopalakrishnan<aravind.gopalakrishnan@amd.com>
serial: expand the PCIe params for an Oxford two port serial cards

Which of course has a different model number and sports two
serial outputs.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Keir Fraser <keir@xen.org>
use domid check in is_hardware_domain

Instead of checking is_privileged to determine if a domain should
control the hardware, check that the domain_id is equal to zero (which
is currently the only domain for which is_privileged is true).  This
allows other places where domain_id is checked for zero to be replaced
with is_hardware_domain.

The distinction between is_hardware_domain, is_control_domain, and
domain 0 is based on the following disaggregation model:

Domain 0 bootstraps the system.  It may remain to perform requested
builds of domains that need a minimal trust chain (i.e. vTPM domains).
Other than being built by the hypervisor, nothing is special about this
domain - although it may be useful to have is_control_domain() return
true depending on the toolstack it uses to build other domains.

The hardware domain manages devices for PCI pass-through to driver
domains or can act as a driver domain itself, depending on the desired
degree of disaggregation.  It is also the domain managing devices that
do not support pass-through: PCI configuration space access, parsing the
hardware ACPI tables and system power or machine check events.  This is
the only domain where is_hardware_domain() is true.  The return of
is_control_domain() may be false for this domain.

The control domain manages other domains, controls guest launch and
shutdown, and manages resource constraints; is_control_domain() returns
true.  The functionality guarded by is_control_domain may in the future
be adapted to use explicit hypercalls, eliminating the special treatment
of this domain.  It may be reasonable to have multiple control domains
on a multi-tenant system.

Guest domains and other service or driver domains are all treated
identically by the hypervisor; the security policy may further constrain
administrative actions on or communication between these domains.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
iommu: Move dom0 setup code to __hwdom_init

When the hardware domain is split from domain 0, the initialization code
for the hardware domain cannot be in the __init section, since the
actual domain creation happens after these sections have been discarded.
Create a __hwdom_init section designator to annotate these functions,
and control it using the XSM configuration option for now (since XSM is
required to take advantage of the security benefits of disaggregation).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
prevent 0 from being used as a dynamic domid

When the hardware domain is made distinct from dom0, it becomes possible
to shut down and destroy domain 0 while leaving the hypervisor running.
If this happens, prevent this domain ID from being considered for
allocation to a new guest.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Keir Fraser <keir@xen.org>