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

…scm/linux/kernel/git/konrad/xen

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.

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));
 }

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)

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)

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)

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);