update Xen version to 4.2.2-rc1
powernow: add fixups for AMD P-state figures

In the Linux kernel, these two git commits:

- f594065faf4f9067c2283a34619fc0714e79a98d
  ACPI: Add fixups for AMD P-state figures
- 9855d8ce41a7801548a05d844db2f46c3e810166
  ACPI: Check MSR valid bit before using P-state frequencies

Try to fix the the issue that "some AMD systems may round the
frequencies in ACPI tables to 100MHz boundaries. We can obtain the real
frequencies from MSRs, so add a quirk to fix these frequencies up
on AMD systems." (from f594065..)

In discussion (around 9855d8..) "it turned out that indeed real
HW/BIOSes may choose to not set the valid bit and thus mark the
P-state as invalid. So this could be considered a fix for broken
BIOSes." (from 9855d8..)

which is great for Linux. Unfortunatly the Linux kernel, when
it tries to do the RDMSR under Xen it fails to get the right
value (it gets zero) as Xen traps it and returns zero. Hence
when dom0 uploads the P-states they will be unmodified and
we should take care of updating the frequencies with the right
values.

I've tested it under Dell Inc. PowerEdge T105 /0RR825, BIOS 1.3.2
08/20/2008 where this quirk can be observed (x86 == 0x10, model == 2).
Also on other AMD (x86 == 0x12, A8-3850; x86 = 0x14, AMD E-350) to
make sure the quirk is not applied there.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: stefan.bader@canonical.com

Do the MSR access here (and while at it, also the one reading
MSR_PSTATE_CUR_LIMIT) on the target CPU, and bound the loop over
amd_fixup_frequency() by max_hw_pstate (matching the one in
powernow_cpufreq_cpu_init()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
master changeset: 1d80765b504b34b63a42a63aff4291e07e29f0c5
master date: 2013-03-12 15:34:22 +0100
x86/MCA: suppress bank clearing for certain injected events

As the bits indicating validity of the ADDR and MISC bank MSRs may be
injected in a way that isn't consistent with what the underlying
hardware implements (while the bank must be valid for injection to
work, the auxiliary MSRs may not be implemented - and hence cause #GP
upon access - if the hardware never sets the corresponding valid bits.

Consequently we need to do the clearing writes only if no value was
interposed for the respective MSR (which also makes sense the other way
around: there's no point in clearing a hardware register when all data
read came from software). Of course this all requires the injection
tool to do things in a consistent way (but that had been a requirement
before already).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ren Yongjie <yongjie.ren@intel.com>
Acked-by: Liu Jinsong <jinsong.liu@intel.com>
master changeset: b0583c0e64cc8bb6229c95c3304fdac2051f79b3
master date: 2013-03-12 15:53:30 +0100
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>
master changeset: 0f7b6f91ac1bbfd33b23c291b14874b9561909d2
master date: 2013-03-20 10:00:01 +0100
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>
master changeset: 32861c537781ac94bf403fb778505c3679b85f67
master date: 2013-03-20 10:02:26 +0100
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 (removed from the
backport).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
master changeset: fae0372140befb88d890a30704a8ec058c902af8
master date: 2013-03-25 14:28:31 +0100
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>
master changeset: 6890cebc6a987d0e896f5d23a8de11a3934101cf
master date: 2013-03-25 14:31:27 +0100
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>
master changeset: 92b8bc03bd4b582cb524db51494d0dba7607e7ac
master date: 2013-03-25 16:55:22 +0100
ACPI/APEI: fix ERST MOVE_DATA instruction implementation

The src_base and dst_base fields in apei_exec_context are physical
address, so they should be ioremaped before being used in ERST
MOVE_DATA instruction.

Reported-by: Javier Martinez Canillas <martinez.javier@gmail.com>
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Huang Ying <ying.huang@intel.com>

Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
handling.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master changeset: df2cf6a726b815fafa12e503c9a36707c3962f22
master date: 2012-10-17 14:12:06 +0200
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>
master changeset: 759847e44401176401e86e7c55b644cb9f93c781
master date: 2013-03-20 10:02:52 +0100
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>
master changeset: 0611689d9153227831979c7bafe594214b8505a3
master date: 2013-03-22 09:43:38 +0100
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>
master changeset: 72af01bf6f7489e54ad59270222a29d3e8c501d1
master date: 2013-03-22 12:46:25 +0100
ACPI: fix APEI related table size checking

On Huang Ying's machine:

erst_tab->header_length == sizeof(struct acpi_table_einj)

but Yinghai reported that on his machine,

erst_tab->header_length == sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)

To make erst table size checking code works on all systems, both
testing are treated as PASS.

Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.

Originally-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Huang Ying <ying.huang@intel.com>

- use switch() for better readability
- add comment explaining why a formally invalid size it also being
  accepted
- check erst_tab->header.length before even looking at
  erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master changeset: 915ef37d7cc8fcac5b37eb0b40c693754fcd12ab
master date: 2012-10-16 17:26:36 +0200
x86: reserve pages when SandyBridge integrated graphics

SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table.

Xen does not initialize below 1MB to heap, i.e. below 1MB pages don't be
allocated, so it's unnecessary to reserve memory below the 1 MB mark
that has not already been reserved.

So reserve those pages listed in the table at xen boot if set detect a
SNB gfx device on the CPU to avoid GPU hangs.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master changeset: db537fe3023bf157b85c8246782cb72a6f989b31
master date: 2013-03-26 14:22:07 +0100
x86/EFI: permit setting variable with non-zero attributes

This must have been a copy-and-paste mistake - get_variable uses
op->misc as output only, and wants to make sure it's zero for future
extensibility. For set_variable, this is an input though, and hence
the check is wrong.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master changeset: 78380c34dfeb27da3d0222bcb7232c5d8e2f5b30
master date: 2013-03-27 08:46:28 +0100
hvm: Clean up vlapic_reg_write() error propagation.

In particular, correctly propagate errors through vlapic_apicv_write()
and hvm_x2apic_msr_write().

Signed-off-by: Keir Fraser <keir@xen.org>
master changeset: 5082cc19524b6687ef1bc0a717538d75aae7cd00
master date: 2013-03-28 20:16:37 +0000
defer event channel bucket pointer store until after XSM checks

Otherwise a dangling pointer can be left, which would cause subsequent
memory corruption as soon as the space got re-allocated for some other
purpose.

This is CVE-2013-1920 / XSA-47.

Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 99b9ab0b3e7f0e7e5786116773cb7b746f3fab87
master date: 2013-04-05 09:59:03 +0200
x86: irq_move_cleanup_interrupt() must ignore legacy vectors

Since the main loop in the function includes legacy vectors, and since
vector_irq[] gets set up for legacy vectors regardless of whether those
get handled through the IO-APIC, it must not do anything on this vector
range. In fact, we should never get past the move_cleanup_count check
for IRQs not handled through the IO-APIC. Adding a respective assertion
woulkd make those iterations more expensive (due to the lock acquire).

For such an assertion to not have false positives we however ought to
suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct
anyway), which is being done here despite the assertion not actually
getting added.

Furthermore, there's no point iterating over the vectors past
LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: af699220ad6d111ba76fc3040342184e423cc9a1
master date: 2013-04-02 08:30:03 +0200
x86/S3: Restore broken vcpu affinity on resume

When in SYS_STATE_suspend, and going through the cpu_disable_scheduler
path, save a copy of the current cpu affinity, and mark a flag to
restore it later.

Later, in the resume process, when enabling nonboot cpus restore these
affinities.

Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 41e71c2607e036f1ac00df898b8f4acb2d4df7ee
master date: 2013-04-02 09:52:32 +0200
VMX: Always disable SMEP when guest is in non-paging mode

commit e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65
  VMX: disable SMEP feature when guest is in non-paging mode

disabled the SMEP bit if a guest VCPU was using HAP and was not
in paging mode. However I could observe VCPUs getting stuck in
the trampoline after the following patch in the Linux kernel
changed the way CR4 gets set up:
  x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline

The change will set CR4 from already set flags which includes the
SMEP bit. On bare metal this does not matter as the CPU is in non-
paging mode at that time. But Xen seems to use the emulated non-
paging mode regardless of HAP (I verified that on the guests I was
seeing the issue, HAP was not used).

Therefor it seems right to unset the SMEP bit for a VCPU that is
not in paging-mode, regardless of its HAP usage.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Dongxiao Xu <dongxiao.xu@intel.com>
master commit: 0d2e673a763bc7c2ddf97fed074eb691d325ecc5
master date: 2013-04-04 10:37:19 +0200