x86/viridian: Re-purpose the HVM parameter to be a feature mask

The following commits introduced the time reference counter MSR and
TSC/APIC frequency MSRs into the viridian feature set respectively:

e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b
84657efd9116f40924aa13c9d5a349e007da716f

The time reference counter MSR feature was then reverted by commit

1cd4fab14ce25859efa4a2af13475e6650a5506c

because a flaw in the implementation meant the counter was reset on
migration.

All of these changes were made without any addtional options being
added to the VM configuration, or any compatibility checks being made
in the domain save/restore code. Hence setting the single boolean
'viridian' option in the VM configuration yields a different set of
features depending on which version of Xen the VM is started on, and the
feature set can change across migration (so new MSRs can magically appear).

This patch grandfathers in the current viridian features set and calls them
the 'base' and 'freq' feature sets. HVM_PARAM_VIRIDIAN is re-purposed as
a feature mask. The hypervisor has only ever allowed it ot be set to 0
or 1, so the presence of the base and freq sets are indicated by setting
bit 0. The freq set can then be turned off by setting bit 1, thus
restoring the pre-Xen-4.4 base set. Newly implemented viridian features
can be optionally enabled in future by setting further bits.

The viridian option in xl.cfg(5) has also been changed to a list so
that the sets can be individually enabled or disabled. For compatibility,
if the option is specified as a boolean, then a true (1) value will enable
the base and freq sets and a false (0) value will not enable any
enlightenments.

This patch also alters the allowed write accesses to HVM_PARAM_VIRIDIAN.
Currently there is nothing to stop the guest writing this value (which,
while harmless to anything else, should not happen) and nothing to
stop a toolstack from setting the value back to zero whilst the guest is
running, causing CPUID leaves to disappear and MSR accesses to start
causing GPFs in the guest. Both of these possibilities are now disallowed:
Once the parameter is set to a non-zero value it may not be modified (only
re-written with the same value), and guests no longer have any write
access.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/viridian: Add partition time reference counter MSR support

This patch optionally re-instates support for the partition time reference
counter that was previously introduced by commit
e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b and reverted by commit
1cd4fab14ce25859efa4a2af13475e6650a5506c. The previous implementation was
non-optional and flawed.

This implementation uses the tsc of vcpu0, which is preserved across
save/restore as part of the architectural state, and then converts that
to a 100ns tick using the domain's tsc_khz.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Christoph Egger <chegger@amazon.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen: arm: Add support for the Exynos secure firmware

The existence of secure firmware is dictated by the presence of
"samsung,secure-firmware" in the DT.

The Arndale board does not have that entry, and uses the address as defined
in "samsung,exynos4210-sysram", offset 0 as the smp init address. This is
possibly true for all SoCs without secure firmware.

For other boards which do have a "secure-firmware" node, use sysram-ns
at offset +0x1c as the smp init address.

The "secure-firmware" MMIO range contains ways to idle the CPU. As this gets
mapped to DOM0 because of its presence in the DT, we blacklist it.

Have tested this on the Odroid XU. I have also tested the other code path
on the Odroid XU by removing "secure-firmware" from its DT. I could see
that the other code path was exercised with correct smp init address
values.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
make: Add subtree-force-update target

subtree-force-update will update all subtrees according to the current TAG specified
in Config.mk.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
make: Make "src-tarball" target actually make a source tarball

At the moment, making a release tarball is an annoyingly manual
process that involves running "git archive" into a temporary directory.

Script this process up and make a target, so that the release manager
can simply type "make src-tarball-release" and have everything show up
nice and neat in dist/xen-$version.tar.gz.  "make src-tarball" will
make a version number based on git describe, which will typically have
the most recent tag, number of commits since that tag, and the git
commit id of the current HEAD.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
libbxl: add support for pvscsi, iteration 1

Add support for vscsi= in domU.cfg, add new xl commands scsi-attach,
scsi-list, scsi-detach. The syntax follows what xend understood.

pvscsi provides a dom0 SCSI device as-is to a domU. The backend and
frontend drivers can be found in xen-linux, or its forward-ported
variants. This patch was tested with an openSUSE dom0 and a SLES12
guest. Any openSUSE/SLE11/SLE12 dom0/domU combination will work.

The domU.cfg syntax is "vscsi=[ 'pdev,vdev[,option]' ]". pdev is the
dom0 device in either /dev/$device or HOST:CHANNEL:TARGET:LUN notation.
vdev is the domU device in HOST:CHANNEL:TARGET:LUN notation.

xl scsi-attach will attach a SCSI device at runtime.
xl scsi-detach will remove a SCSI drivce at runtime.
xl scsi-list lists SCSI devices for a list of domains.

The backend driver uses a single_host:many_devices notation to manage
domU devices. The xenstore layout looks like this:

/local/domain/0/backend/vscsi/<domid>/<vhost>/feature-host = "0"
/local/domain/0/backend/vscsi/<domid>/<vhost>/frontend = "/local/domain/<domid>/device/vscsi/0"
/local/domain/0/backend/vscsi/<domid>/<vhost>/frontend-id = "<domid>"
/local/domain/0/backend/vscsi/<domid>/<vhost>/online = "1"
/local/domain/0/backend/vscsi/<domid>/<vhost>/state = "4"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-0/p-dev = "8:0:2:1"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-0/state = "4"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-0/v-dev = "0:0:0:0"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-1/p-dev = "8:0:2:2"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-1/state = "4"
/local/domain/0/backend/vscsi/<domid>/<vhost>/vscsi-devs/dev-1/v-dev = "0:0:1:0"

/local/domain/<domid>/device/vscsi/<vhost>/backend = "/local/domain/0/backend/vscsi/<domid>/<vhost>"
/local/domain/<domid>/device/vscsi/<vhost>/backend-id = "0"
/local/domain/<domid>/device/vscsi/<vhost>/event-channel = "20"
/local/domain/<domid>/device/vscsi/<vhost>/ring-ref = "43"
/local/domain/<domid>/device/vscsi/<vhost>/state = "4"
/local/domain/<domid>/device/vscsi/<vhost>/vscsi-devs/dev-0/state = "4"
/local/domain/<domid>/device/vscsi/<vhost>/vscsi-devs/dev-1/state = "4"

This is a challenge for libxl because libxl currently handles only
single_host:single_device in its device helper functions.  Due to this
limitation in libxl, scsi-detach will remove the whole virtual scsi host
with all its virtual devices, instead of just the requested single
virtual device.  scsi-attach can cope with this limitation because it
could write the required files directly into xenstore to attach yet
another virtual scsi device to an existing virtual scsi host. However,
this functionality is currently not implemented.

To support the pdev notation '/dev/$device' it is required to parse
sysfs to translate the path to HST:CHN:TGT:LUN notation. In its current
variant /sys/dev/ is used, which is available since at least Linux 3.0.
Support for dom0 kernels which lack this interface will be added later.

This is a draft patch to get it out of the door, to get help with
solving the libxl limitation above, and of course for public code review.
In this first iteration:
 - the domU.cfg parser for vscsi=[] is functional.
 - xl scsi-list will print output similar to its xm counter part.
 - xl scsi-detach will remove entire scsi hosts, unlike its xm counter part.
 - xl scsi-attach is not yet implemented.
 - coding style may be way off in some parts of the new code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ondrej Holecek <oholecek@suse.com>
pvscsi: scsi-detach, scsi-attach

Signed-off-by: Olaf Hering <olaf@aepfle.de>