passthrough/PCI: replace improper uses of pci_find_next_cap()

Using pci_find_next_cap() without prior pci_find_cap_offset() is bogus
(and possibly wrong, given that the latter doesn't check the
PCI_STATUS_CAP_LIST flag, which so far was checked in an open-coded way
only for the non-bridge case).

Once at it, fold the two calls into one, as we need its result in any
case.

Question is whether, without any caller left, pci_find_next_cap()
should be purged as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
xend: reinstate XendOptionsFile.get_external_migration_tool

This was removed by 26167:31dcc0e08754 "xend: Remove old vtpm support
from xm" but at least one caller was left. Reinstate with
s/TPM/device/ since it appears that this functionality could apply
elsewhere.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
VT-d: clean up map/unmap log messages

- printing file name and line number here is pointless
- they are guest related, so should get their log level filter
  accordingly
- include segment numbers and canonicalize number widths

Signed-off-by: Jan Beulich <jbeulich@suse.com>
x86/HPET: include FSB interrupt information in 'M' debug key output

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
x86/HPET: fix FSB interrupt masking

HPET_TN_FSB is not really suitable for masking interrupts - it merely
switches between the two delivery methods. The right way of masking is
through the HPET_TN_ENABLE bit (which really is an interrupt enable,
not a counter enable or some such). This is even more so with certain
chip sets not even allowing HPET_TN_FSB to be cleared on some of the
channels.

Further, all the setup of the channel should happen before actually
enabling the interrupt, which requires splitting legacy and FSB logic.

Finally this also fixes an S3 resume problem (HPET_TN_FSB did not get
set in hpet_broadcast_resume(), and hpet_msi_unmask() doesn't get
called from the general resume code either afaict).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
implement vmap()

... and use it as basis for a proper ioremap() on x86.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xl: Suppress spurious warning message for cpupool-list

libxl_cpupool_list() enumerates the cpupools by "probing": calling
cpupool_info, starting at 0 and stopping when it gets an error. However,
cpupool_info will print an error when the call to xc_cpupool_getinfo() fails,
resulting in every xl command that uses libxl_list_cpupool (such as
cpupool-list) printing that error message spuriously.

Since at the moment the times we want to print the message correspond
with the use of the existing "exact" parameter, use it to decide
whether to print the message or not.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
arm: Tidy up flush_xen_dcache().

 - Use a compile-time-constant check for whether we can safely flush
   just one cacheline.  This reduces the common case from 28
   instructions to three.
 - Pass an object to the macro, not a pointer, so we can detect
   attempts to flush arrays.
 - Decode CCSIDR correctly to get cacheline size.
 - Remove some redundant DSBs at the call sites.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xend: enable environment passing in xPopen3

In changeset 19990:38dd208e1d95 a new parameter 'env' was added to
xPopen3, but no code was added to actually pass the environment down to
execvpe. Also, the new code was unreachable.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
x86/time: fix scale_delta() inline assembly

The way it was coded, it clobbered %rdx without telling the compiler.
This generally didn't cause any problems except when there are two back
to back invocations (as in plt_overflow()), as in that case the
compiler may validly assume that it can re-use for the second instance
the value loaded into %rdx before the first one.

Once at it, also properly relax the second operand of "mul" (there's no
need for it to be in %rdx, or a register at all), and switch away from
using explicit register names in the instruction operands.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xenstore-chmod: handle arbitrary number of perms rather than MAX_PERMS constant

Constant MAX_PERMS 16 is too small to use in some occasions, e.g. if
there are more than 16 domU(s) on one hypervisor (it's easy to
achieve) and one wants to do xenstore-chmod PATH to all domU(s). So,
remove MAX_PERMS limitation and make it as arbitrary number of perms.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
libxl: fix a variable underflow in libxl_wait_for_free_memory

When xl is called to create a domU and there is not enough memory available,
then the autoballooning is called to extract memory from dom0. During the
ballooning a loop in libxl_wait_for_free_memory() waits unless enough memory
is available to create the domU.

But because of a variable-underflow the loop can finish too soon and xl
finally aborts with the message:

xc: error: panic: xc_dom_boot.c:161: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory
libxl: error: libxl_dom.c:430:libxl__build_pv: xc_dom_boot_mem_init failed: Device or resource busy
libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot (re-)build domain: -3

The variable-underflow happens when freemem_slack is larger then
info.free_pages*4, because the solution of this operation is converted
implicit to a unsigned int to match the type of memory_kb.

Add a extra check for this condition to solve the problem.

Signed-off-by: Ronny Hegewald <Ronny.Hegewald@online.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
README: add Pixman as build dependency

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xl: xl.conf(5): correct advice re autoballooning vs. dom0_mem.

The advice was backwards, you should really disable autoballoon if you
use dom0_mem. Also add a reference to the command-line docs.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
libxl: Fix bug in libxl_cdrom_insert, make more robust against bad xenstore data

libxl_cdrom_insert was failing to initialize the backend type,
resulting in the wrong default backend.  The result was not only that
the CD was not inserted properly, but also that some improper xenstore
entries were created, causing further block commands to fail.

This patch fixes the bug by setting the disk backend type based on the
type of the existing device.

It also makes the system more robust by checking to see that it has
got a valid path before proceeding to write a partial xenstore entry.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>