MAINTAINERS: Remove myself from AMD IOMMU maintainer

Signed-off-by: Wei Wang <wawei@amazon.com>
x86/HPET: mask interrupt while changing affinity

While being unable to reproduce the "No irq handler for vector ..."
messages observed on other systems, the change done by 5dc3fd2 ('x86:
extend diagnostics for "No irq handler for vector" messages') appears
to point at the lack of masking - at least I can't see what else might
be wrong with the HPET MSI code that could trigger these warnings.

While at it, also adjust the message printed by aforementioned commit
to not pointlessly insert spaces - we don't need aligned tabular output
here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
oxenstored: Re-add ocaml syslog binding

This was lost in the OCaml xenstored log merge of 10/Oct/2011.

The binding isn't exported as a shared "log" library, instead it is kept
local to xenstored.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
oxenstored: enable logging via syslog, if specified in the config file.

To log to files the config file should contain:
   xenstored-log-file = /var/log/xenstored.log
   access-log-file = /var/log/xenstored-access.log

(These two files are still the built-in defaults. The log format is
unchanged.)

To log to syslog the config file should contain:
   xenstored-log-file = syslog:<facility>
   access-log-file = syslog:<facility>

where <facility> is the syslog facility to use (e.g. 'daemon' 'local2')

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
oxenstored: Allow oxenstored to use syslog at levels other than Debug

We now log different kinds of events at different levels. The convention
is now:

new/end_connection:    Debug
coalesce:              Debug
conflict:              Debug
commit:                Debug
regular ops:           Info
start/end_transaction: Debug
error (ENOENT):        Debug
error (any other):     Warn
watch:                 Info

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
AMD/IOMMU: Process softirqs while building dom0 iommu mappings

Recent changes which have made their way into xen-4.2 stable have pushed the
runtime of construct_dom0() over 5 seconds, which has caused regressions in
XenServer testing because of our 5 second watchdog.

The root cause is that amd_iommu_dom0_init() does not process softirqs and in
particular the nmi_timer which causes the watchdog to decide that no useful
progress is being made.

This patch adds periodic calls to process_pending_softirqs() at the same
interval as the Intel variant of this function.  The server which was failing
with the watchdog test now boots reliably with a timeout of 1 second.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86: BITS_PER_LONG is now always 64

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
VT-d: Enumerate IOMMUs when listing capabilities

This saves N identical console log lines on a multi-iommu server.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
ACPI/ERST: Name table in otherwise opaque error messages

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Fix spelling and lower severities.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
x86/HPET: deal with event having expired while interrupt was masked

Commit 2d8a282 ("x86/HPET: fix FSB interrupt masking") may cause the
HPET event to occur while its interrupt is masked. In that case we need
to "manually" deliver the event.

Unfortunately this requires the locking to be changed: For one, it was
always bogus for handle_hpet_broadcast() to use spin_unlock_irq() - the
function is being called from an interrupt handler, and hence shouldn't
blindly re-enable interrupts (this should be left up to the generic
interrupt handling code). And with the event handler wanting to acquire
the lock for two of its code regions, we must not enter it with the
lock already held. Hence move the locking into
hpet_{attach,detach}_channel(), permitting the lock to be dropped by
set_channel_irq_affinity() (which is a tail call of those functions).

Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Keir Fraser <keir@xen.org>
ACPI/APEI: Unlock apei_iomaps_lock on error path

This causes deadlocks during early boot on hardware with broken/buggy
APEI implementations, such as a Dell Poweredge 2950 with the latest
currently available BIOS.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Don't use goto or another special error path, as handling the error
case in normal flow is quite simple.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
ACPI, APEI: Add apei_exec_run_optional

Some actions in APEI ERST and EINJ tables are optional, for example,
ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for
error injection, and firmware may choose to do nothing here.  While
some other actions are mandatory, for example, firmware must provide
ACPI_EINJ_GET_ERROR_TYPE implementation.

Original implementation treats all actions as optional (that is, can
have no instructions), that may cause issue if firmware does not
provide some mandatory actions.  To fix this, this patch adds
apei_exec_run_optional, which should be used for optional actions.
The original apei_exec_run should be used for mandatory actions.

Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
tools/firmware: Fix ovmf build with gcc version different from 4.4

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
tools: Retry blktap2 tapdisk message on interrupt.

Re-start blktap2 IPC select call on interrupt.

We hunted this miserable bug for a long time.

The teardown of a blktap2 tapdisk instance is being carried out
inconsistently up to and including the 4.2.1 release.  The
problem appears to be a classic 'Heisenbug' which disappears if a
single function call is added to the tapdisk shutdown path.  It
is likely this bug has been in existence for the life of the
blktap2 code.

Control messages to manipulate a tapdisk instance are sent over a
UNIX domain socket.  A select call is used on both the read and
write paths to wait on I/O and to set a timeout for the
transmission and reception of the control plane messages.

The existing code fails receipt or transmission of the control message
on any type of error return from the select call.  The xl control
process receives an interrupt while waiting in the select call which
in turn causes an error return with SIGINT as the return code.

This prematurely terminates the teardown of the tapdisk instance
leaving it in various states of shutdown.  Since multiple messages
are needed to implement a full teardown the tapdisk instance can be
left in various states ranging from fully connected to only the minor
being left allocated.

The fix is straight forward.  Check the return code from the
select call and re-try read or write of the control message if
errno is sent to EINTR.  The problem manifests itself in the read
path but there appears to be little reason to not add the fix to
the write path as well.  Both paths appear to be cut-and-paste
copies of each other.

Signed-off-by: Dr. Greg Wettstein <greg@enjellic.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: Streamline vnc argument generation code

Makes the following changes to the vnc generation code:
* Simplifies and comments it, making it easier to read and grok
* Throws an error if duplicate values of display are set, rather
  than the current very un-intuitive behavior.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
xenconsoled: use array index to keep track of pollfd

If we use pointers to reference elements inside array, it is possible that we
get wild pointer after realloc(3) copies array and returns a new pointer.

Keep track of element indexes inside the array can solve this problem.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marcus Granado <marcus.granado@citrix.com>
Tested-by: Marcus Granado <marcus.granado@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
IOMMU: properly check whether interrupt remapping is enabled

... rather than the IOMMU as a whole.

That in turn required to make sure iommu_intremap gets properly
cleared when the respective initialization fails (or isn't being
done at all).

Along with making sure interrupt remapping doesn't get inconsistently
enabled on some IOMMUs and not on others in the VT-d code, this in turn
allowed quite a bit of cleanup on the VT-d side (if desired, that
cleanup could of course be broken out into a separate patch).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
VT-d: deal with 5500/5520/X58 errata

http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html

Stepping B-3 has two errata (#47 and #53) related to Interrupt
remapping, to which the workaround is for the BIOS to completely disable
interrupt remapping.  These errata are fixed in stepping C-2.

Unfortunately this chipset stepping is very common and many BIOSes are
not disabling interrupt remapping on this stepping .  We can detect this in
Xen and prevent Xen from using the problematic interrupt remapping feature.

The Intel 5500/5520/X58 chipset does not support VT-d
Extended Interrupt Mode(EIM). This means the iommu_supports_eim() check
always fails and so x2apic mode cannot be enabled in Xen before this quirk
disables the interrupt remapping feature.

Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Gate the function call to check the quirk on interrupt remapping being
requested to get enabled, and upon failure disable the IOMMU to be in
line with what the changes for XSA-36 (plus follow-ups) did.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
AMD IOMMU: allow disabling only interrupt remapping when certain IVRS consistency checks fail

After some more thought on the XSA-36 and specifically the comments we
got regarding disabling the IOMMU in this situation altogether making
things worse instead of better, I came to the conclusion that we can
actually restrict the action in affected cases to just disabling
interrupt remapping. That doesn't make the situation worse than prior
to the XSA-36 fixes (where interrupt remapping didn't really protect
domains from one another), but allows at least DMA isolation to still
be utilized.

To do so, disabling of interrupt remapping must be explicitly requested
on the command line - respective checks will then be skipped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
trace: Use correct trace class for power management changes

Previous to this patch we would see in the trace file:

CPU28  1753503175371 (+    8496)  unknown (0x0000000000801002)  [ 0x00000004 0x4158a498 0x000003a1 0x000027e6 0x00000000 0x00000000 0x00000000 ]
CPU28  1753505321239 (+ 2145868)  unknown (0x0000000000801003)  [ 0x00000004 0x4166dca7 0x000000fa 0x00000000 0x00000000 0x00000000 0x00000000 ]
CPU28  1753505343756 (+   22517)  unknown (0x0000000000801002)  [ 0x00000004 0x41670fe5 0x00001284 0x00003766 0x00000000 0x00000000 0x00000000 ]
CPU28  1753521413711 (+16069955)  unknown (0x0000000000801003)  [ 0x00000004 0x41d1e02c 0x000000ab 0x00000000 0x00000000 0x00000000 0x00000000 ]

instead of:
CPU28  1753503175371 (+    8496)  cpu_idle_entry  [ C0 -> C4, acpi_pm_tick = 1096328344, expected = 929us, predicted = 10214us ]
CPU28  1753505321239 (+ 2145868)  cpu_idle_exit   [ C4 -> C0, acpi_pm_tick = 1097260199, irq = 250 0 0 0 ]
CPU28  1753505343756 (+   22517)  cpu_idle_entry  [ C0 -> C4, acpi_pm_tick = 1097273317, expected = 4740us, predicted = 14182us ]
CPU28  1753521413711 (+16069955)  cpu_idle_exit   [ C4 -> C0, acpi_pm_tick = 1104273452, irq = 171 0 0 0 ]

The patch that added the cpu_idle_[entry|exit] was using the
TRC_HW_IRQ class (0x00802000) instead of TRC_HW_PM (0x00801000)
as a base.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>