Merge tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel...

Pull Xen fixes from Konrad Rzeszutek Wilk:
 "Some of these had been in existence since the 2.6.27 days, some since
  3.0 - and some due to new features added in v3.4.

  The one that is most interesting is David's one - in the low-level
  assembler code we had be checking events needlessly.  With his patch
  now we do it when the appropriate flag is set - with the added benefit
  that we can process events faster.  Stefano's is fixing a mistake
  where the Linux IRQ numbers were ACK-ed instead of the Xen IRQ,
  resulting in missing interrupts.  The other ones are bootup related
  that can show up on various hardware."

 - In the low-level assembler code we would jump to check events even if
   none were present.  This incorrect behavior had been there since
   2.6.27 days!
 - When using the fast-path for ACK-ing interrupts we were using the
   Linux IRQ numbers instead of the Xen ones (and they can differ) and
   missing interrupts in process.
 - Fix bootup crashes when ACPI hotplug CPUs were present and they would
   expand past the set number of CPUs we were allocated.
 - Deal with broken BIOSes when uploading C-states to the hypervisor.
 - Disable the cpuid check for MWAIT_LEAF if the ACPI PAD driver is
   loaded.  If the ACPI PAD driver is used it will crash, so lets not
   export the functionality so the ACPI PAD driver won't load.

* tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen: correctly check for pending events when restoring irq flags
  xen/acpi: Workaround broken BIOSes exporting non-existing C-states.
  xen/smp: Fix crash when booting with ACPI hotplug CPUs.
  xen: use the pirq number to check the pirq_eoi_map
  xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4f51bebac02c1493c5ed9a606327bf854b22be91..a8f8844b8d32690b8a189bc37d12cd3f286a81cd 100644 (file)
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -261,7 +261,8 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 
 static bool __init xen_check_mwait(void)
 {
-#ifdef CONFIG_ACPI
+#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && \
+       !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
        struct xen_platform_op op = {
                .cmd                    = XENPF_set_processor_pminfo,
                .u.set_pminfo.id        = -1,
@@ -349,7 +350,6 @@ static void __init xen_init_cpuid_mask(void)
        /* Xen will set CR4.OSXSAVE if supported and not disabled by force */
        if ((cx & xsave_mask) != xsave_mask)
                cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
-
        if (xen_check_mwait())
                cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
 }

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fac6919b957fa88a9b9cc130007671ffbc00d13..0503c0c493a9a64bf44b41fb237831cb290203fc 100644 (file)
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -178,6 +178,7 @@ static void __init xen_fill_possible_map(void)
 static void __init xen_filter_cpu_maps(void)
 {
        int i, rc;
+       unsigned int subtract = 0;
 
        if (!xen_initial_domain())
                return;
@@ -192,8 +193,22 @@ static void __init xen_filter_cpu_maps(void)
                } else {
                        set_cpu_possible(i, false);
                        set_cpu_present(i, false);
+                       subtract++;
                }
        }
+#ifdef CONFIG_HOTPLUG_CPU
+       /* This is akin to using 'nr_cpus' on the Linux command line.
+        * Which is OK as when we use 'dom0_max_vcpus=X' we can only
+        * have up to X, while nr_cpu_ids is greater than X. This
+        * normally is not a problem, except when CPU hotplugging
+        * is involved and then there might be more than X CPUs
+        * in the guest - which will not work as there is no
+        * hypercall to expand the max number of VCPUs an already
+        * running guest has. So cap it up to X. */
+       if (subtract)
+               nr_cpu_ids = nr_cpu_ids - subtract;
+#endif
+
 }
 
 static void __init xen_smp_prepare_boot_cpu(void)

diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
index 79d7362ad6d1f0e0a6fab6aad37700e2a5dd038a..3e45aa000718aa2cd63d78f5c849e42666905d0e 100644 (file)
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct)
 
        /* check for unmasked and pending */
        cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
-       jz 1f
+       jnz 1f
 2:     call check_events
 1:
 ENDPATCH(xen_restore_fl_direct)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 4b33acd8ed4ef262bfa43940eab2be7a3deb66f5..0a8a17cd80bea172d767f02609b0164b45fe1717 100644 (file)
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -274,7 +274,7 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 
 static bool pirq_check_eoi_map(unsigned irq)
 {
-       return test_bit(irq, pirq_eoi_map);
+       return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
 
 static bool pirq_needs_eoi_flag(unsigned irq)

diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index 174b5653cd8afd7b1ca9190d73e87e9d72f2694b..0b48579a9cd6066c170741913875ebbe716dce0c 100644 (file)
--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -128,7 +128,10 @@ static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
                        pr_debug("     C%d: %s %d uS\n",
                                 cx->type, cx->desc, (u32)cx->latency);
                }
-       } else
+       } else if (ret != -EINVAL)
+               /* EINVAL means the ACPI ID is incorrect - meaning the ACPI
+                * table is referencing a non-existing CPU - which can happen
+                * with broken ACPI tables. */
                pr_err(DRV_NAME "(CX): Hypervisor error (%d) for ACPI CPU%u\n",
                       ret, _pr->acpi_id);