MAINTAINERS: add Kevin Tian to "INTEL(R) VT FOR X86 (VT-X)" part

Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
x86: Intel CPU family update

... according to revision 49 of the Intel SDM.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/idle: update to include further package/core residency MSRs

With the number of these growing it becomes increasingly desirable to
not repeatedly alter the sysctl interface to accommodate them. Replace
the explicit listing of numbered states by arrays, unused fields of
which will remain untouched by the hypercall.

The adjusted sysctl interface at once fixes an unrelated shortcoming
of the original one: The "nr" field, specifying the size of the
"triggers" and "residencies" arrays, has to be an input (along with
being an output), which the previous implementation didn't obey to.

Note that the bouncing direction in the libxc interface at once gets
corrected to OUT (was BOTH).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
libxc: Fix buffer length for get_suspend_file

Declaring a formal parameter to have an array type doesn't result in
the parameter actually having an array type.  The type is "adjusted"
to a pointer.  (C99 6.9.1(7), 6.7.5.3.)

So the use of sizeof in xc_suspend.c:get_suspend_file was wrong.
Instead, use the #define.  Also get rid of the array size, as it is
misleading.

Newer versions of gcc warn about the erroneous code:
  xc_suspend.c:39:25: error: argument to 'sizeof' in 'snprintf' call
    is the same expression as the destination; did you mean to provide
    an explicit length? [-Werror=sizeof-pointer-memaccess]

Reported-By: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Julien Grall <julien.grall@linaro.org>

--
v2: Actually change the declaration of buf.
xen: arm: map memory as inner shareable.

The inner shareable domain contains all SMP processors, including different
clusters (e.g. big.LITTLE). Therefore this is the correct thing to use for Xen
memory mappings. The outer shareable domain is for devices on busses which are
coherent and barrier-aware (e.g. AMBA4 AXI with ACE). While the system domain
is for things behind bridges which are not.

One wrinkle is that Normal memory with attributes Inner Non-cacheable, Outer
Non-cacheable (which we call BUFFERABLE) must be mapped Outer Shareable on ARM
v7. Therefore change the prototype of mfn_to_xen_entry to take the attribute
index so we can DTRT. On ARMv8 the sharability is ignored and considered to
always be Outer Shareable.

Don't adjust the barriers, flushes etc, those remain as they were (which is
more than is now required).  I'll change those in a later patch.

Many thanks to Leif for explaining the difference between Inner- and
Outer-Shareable in words of two or less syllables, I hope I've replicated that
explanation properly above!

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Only upgrade guest barriers to inner shareable.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen: arm: consolidate barrier definitions

These are effectively identical on both 32- and 64-bit.

The only difference is that they implicit "sy" on 32-bit becomes explicit.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xen: arm: Use SMP barriers when that is all which is required.

SMP barriers can be used when all we care about is synchronising against other
processors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen: arm: Use dmb for smp barriers

The full power of dsb is not required in this context.

Also change wmb() to be dsb() directly instead of indirectly via mb(), for
clarity.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen: arm: add scope to dsb and dmb macros

Everywhere currently passes "sy"stem, so no actual change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen: arm: weaken SMP barriers to inner shareable.

Since all processors are in the inner-shareable domain and we map everything
that way this is sufficient.

The non-SMP barriers remain full system. Although in principle they could
become outer shareable barriers for some hardware this would require us to
know which class a given device is. Given the small number of device drivers
in Xen itself its probably not worth worrying over, although maybe someone
will benchmark at some point.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen: arm: use more specific barriers for read and write barriers.

Note that 32-bit does not provide a load variant of the inner shareable
barrier, so that remains a full any-any barrier.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
xen: arm: make stage 2 page tables walks inner-shareable

The comment was previously incorrect and indicated that these mappings were
unshared (00) when in reality the register was set for outer-shareable (01).

Clarify ORGN0/IRGN0 in the comments while at it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: avoid "PV" terminology

Xen on ARM guests are neither PV nor HVM, they are just "guests". Avoid the
incorrect use of the term pv in the guest type macros.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: fixup a couple of coding style issues

The if in domain.c was only syntactically valid because the macro happened to
contain enclosing braces.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
tools/libxl: libxl_list_domain: fix typo in error message

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools/console: reset tty when xenconsole fails

If xenconsole (the client program) fails, it calls err.  This would
previously neglect to reset the user's terminal to sanity.  Use atexit
to do so.

This routinely happens in Xen 4.4 RC5 with pygrub because libxl
writes the value "" to the tty xenstore key when using xenconsole.
After this patch this just results in a harmless error message.

Reported-by: M A Young <m.a.young@durham.ac.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: M A Young <m.a.young@durham.ac.uk>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

---
v2: Fix whitespace error (reintroduce hard tab)
    Fix commit message not to claim ignorance about root cause
tools/console: xenconsole tolerate tty errors

Since 28d386fc4341 (XSA-57), libxl writes an empty value for the
console tty node, with read-only permission for the guest, when
setting up pv console "frontends".  (The actual tty value is later set
by xenconsoled.)   Writing an empty node is not strictly necessary to
stop the frontend from writing dangerous values here, but it is a good
belt-and-braces approach.

Unfortunately this confuses xenconsole.  It reads the empty value, and
tries to open it as the tty.  xenconsole then exits.

Fix this by having xenconsole treat an empty value the same way as no
value at all.

Also, make the error opening the tty be nonfatal: we just print a
warning, but do not exit.  I think this is helpful in theoretical
situations where xenconsole is racing with libxl and/or xenconsoled.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>

---
v2: Combine two conditions and move the free
libxl: Make libxl_exec tolerate foofd<=2

Make passing 0, 1, or 2 as stdinfd, stdoutfd or stderrfd work
properly.

Also, document the meaning of the fd arguments.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monne <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
libxl: hotplug scripts: stdout >& stderr

Plumb hotplug scripts' stdout to stderr.  That way if they print
anything (which really they shouldn't), it won't get mixed up with
the application's stdout.  (Eg, perhaps with an xl migration
stream...)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <ian.campbell@citrix.com>