[Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Jiang Liu]

Hi Thomas,
	This patch set includes three hotfixes related Xen IRQ for v3.19.
Sorry for the long delay to get these two regressions fixed, it really
cost me some time to read and understand Xen IRQ code.

Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
too once it reaches the mainstream kernel.

Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
It's a temporary solution, I will send the formal fix for v3.20 and
it has passed tests too.

Patch 3 fixes an issue found when reading code. There's no real bug
reports related to this issue yet.

Great thanks to Konrad and Sander for testing fixes for these regressions.

Regards,
Gerry

Jiang Liu (3):
  xen/pci: Kill function xen_setup_acpi_sci()
  xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
    cffe0a2b5a34
  xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

 arch/x86/include/asm/acpi.h |    1 +
 arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
 arch/x86/pci/xen.c          |   49 ++-----------------------------------------
 drivers/acpi/pci_irq.c      |    1 -
 4 files changed, 16 insertions(+), 61 deletions(-)

-- 
1.7.10.4

[Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()

[Jiang Liu]

Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
that is initialize irq for ACPI SCI at early stage in a special way as:
xen_init_IRQ()
	->pci_xen_initial_domain()
		->xen_setup_acpi_sci()
			Allocate and initialize irq for ACPI SCI

Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
IOAPIC irqdomains through following path
acpi_gsi_to_irq()
	->mp_map_gsi_to_irq()
		->mp_map_pin_to_irq()
			->check IOAPIC irqdomain

For PV domains, it uses Xen event based interrupt manangement and
doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
This causes Xen domain0 fails to install interrupt handler for ACPI SCI
and all ACPI events will be lost. Please refer to:
https://lkml.org/lkml/2014/12/19/178

So the fix is to get rid of special treatment for ACPI SCI, just treat
ACPI SCI as normal GSI interrupt as:
acpi_gsi_to_irq()
	->acpi_register_gsi()
		->acpi_register_gsi_xen()
			->xen_register_gsi()

With above change, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
---
 arch/x86/kernel/acpi/boot.c |   26 ++++++++++++------------
 arch/x86/pci/xen.c          |   47 -------------------------------------------
 2 files changed, 13 insertions(+), 60 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index d1626364a28a..b9e30daa0881 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -611,20 +611,20 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
 
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-	int irq;
-
-	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
-		*irqp = gsi;
-	} else {
-		mutex_lock(&acpi_ioapic_lock);
-		irq = mp_map_gsi_to_irq(gsi,
-					IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
-		mutex_unlock(&acpi_ioapic_lock);
-		if (irq < 0)
-			return -1;
-		*irqp = irq;
+	int rc, irq, trigger, polarity;
+
+	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
+	if (rc == 0) {
+		trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+		polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+		irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+		if (irq >= 0) {
+			*irqp = irq;
+			return 0;
+		}
 	}
-	return 0;
+
+	return -1;
 }
 EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index c489ef2c1a39..6e5e89c3c644 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -471,52 +471,6 @@ int __init pci_xen_hvm_init(void)
 }
 
 #ifdef CONFIG_XEN_DOM0
-static __init void xen_setup_acpi_sci(void)
-{
-	int rc;
-	int trigger, polarity;
-	int gsi = acpi_sci_override_gsi;
-	int irq = -1;
-	int gsi_override = -1;
-
-	if (!gsi)
-		return;
-
-	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
-	if (rc) {
-		printk(KERN_WARNING "xen: acpi_get_override_irq failed for acpi"
-				" sci, rc=%d\n", rc);
-		return;
-	}
-	trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
-	polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
-
-	printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
-			"polarity=%d\n", gsi, trigger, polarity);
-
-	/* Before we bind the GSI to a Linux IRQ, check whether
-	 * we need to override it with bus_irq (IRQ) value. Usually for
-	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-	 * but there are oddballs where the IRQ != GSI:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-	 * which ends up being: gsi_to_irq[9] == 20
-	 * (which is what acpi_gsi_to_irq ends up calling when starting the
-	 * the ACPI interpreter and keels over since IRQ 9 has not been
-	 * setup as we had setup IRQ 20 for it).
-	 */
-	if (acpi_gsi_to_irq(gsi, &irq) == 0) {
-		/* Use the provided value if it's valid. */
-		if (irq >= 0)
-			gsi_override = irq;
-	}
-
-	gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
-	printk(KERN_INFO "xen: acpi sci %d\n", gsi);
-
-	return;
-}
-
 int __init pci_xen_initial_domain(void)
 {
 	int irq;
@@ -527,7 +481,6 @@ int __init pci_xen_initial_domain(void)
 	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
 	pci_msi_ignore_mask = 1;
 #endif
-	xen_setup_acpi_sci();
 	__acpi_register_gsi = acpi_register_gsi_xen;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
-- 
1.7.10.4

[Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()

[Jiang Liu]

Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
that is initialize irq for ACPI SCI at early stage in a special way as:
xen_init_IRQ()
	->pci_xen_initial_domain()
		->xen_setup_acpi_sci()
			Allocate and initialize irq for ACPI SCI

Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
IOAPIC irqdomains through following path
acpi_gsi_to_irq()
	->mp_map_gsi_to_irq()
		->mp_map_pin_to_irq()
			->check IOAPIC irqdomain

For PV domains, it uses Xen event based interrupt manangement and
doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
This causes Xen domain0 fails to install interrupt handler for ACPI SCI
and all ACPI events will be lost. Please refer to:
https://lkml.org/lkml/2014/12/19/178

So the fix is to get rid of special treatment for ACPI SCI, just treat
ACPI SCI as normal GSI interrupt as:
acpi_gsi_to_irq()
	->acpi_register_gsi()
		->acpi_register_gsi_xen()
			->xen_register_gsi()

With above change, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
---
 arch/x86/kernel/acpi/boot.c |   26 ++++++++++++------------
 arch/x86/pci/xen.c          |   47 -------------------------------------------
 2 files changed, 13 insertions(+), 60 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index d1626364a28a..b9e30daa0881 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -611,20 +611,20 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
 
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-	int irq;
-
-	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
-		*irqp = gsi;
-	} else {
-		mutex_lock(&acpi_ioapic_lock);
-		irq = mp_map_gsi_to_irq(gsi,
-					IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
-		mutex_unlock(&acpi_ioapic_lock);
-		if (irq < 0)
-			return -1;
-		*irqp = irq;
+	int rc, irq, trigger, polarity;
+
+	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
+	if (rc == 0) {
+		trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+		polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+		irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+		if (irq >= 0) {
+			*irqp = irq;
+			return 0;
+		}
 	}
-	return 0;
+
+	return -1;
 }
 EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index c489ef2c1a39..6e5e89c3c644 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -471,52 +471,6 @@ int __init pci_xen_hvm_init(void)
 }
 
 #ifdef CONFIG_XEN_DOM0
-static __init void xen_setup_acpi_sci(void)
-{
-	int rc;
-	int trigger, polarity;
-	int gsi = acpi_sci_override_gsi;
-	int irq = -1;
-	int gsi_override = -1;
-
-	if (!gsi)
-		return;
-
-	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
-	if (rc) {
-		printk(KERN_WARNING "xen: acpi_get_override_irq failed for acpi"
-				" sci, rc=%d\n", rc);
-		return;
-	}
-	trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
-	polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
-
-	printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
-			"polarity=%d\n", gsi, trigger, polarity);
-
-	/* Before we bind the GSI to a Linux IRQ, check whether
-	 * we need to override it with bus_irq (IRQ) value. Usually for
-	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-	 * but there are oddballs where the IRQ != GSI:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-	 * which ends up being: gsi_to_irq[9] == 20
-	 * (which is what acpi_gsi_to_irq ends up calling when starting the
-	 * the ACPI interpreter and keels over since IRQ 9 has not been
-	 * setup as we had setup IRQ 20 for it).
-	 */
-	if (acpi_gsi_to_irq(gsi, &irq) == 0) {
-		/* Use the provided value if it's valid. */
-		if (irq >= 0)
-			gsi_override = irq;
-	}
-
-	gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
-	printk(KERN_INFO "xen: acpi sci %d\n", gsi);
-
-	return;
-}
-
 int __init pci_xen_initial_domain(void)
 {
 	int irq;
@@ -527,7 +481,6 @@ int __init pci_xen_initial_domain(void)
 	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
 	pci_msi_ignore_mask = 1;
 #endif
-	xen_setup_acpi_sci();
 	__acpi_register_gsi = acpi_register_gsi_xen;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
-- 
1.7.10.4

[Bugfix 2/3] xen/irq, ACPI: Fix regression in xen PCI passthrough caused by cffe0a2b5a34

[Jiang Liu]

Xen pciback driver assumes that pci_dev->irq won't change after calling
pci_disable_device(). But commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687
("x86, irq: Keep balance of IOAPIC pin reference count") frees irq
resources and resets pci_dev->irq to zero when pci_disable_device() is
called.

So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and
another proper fix will be prepared for next merging window.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
---
 drivers/acpi/pci_irq.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 5277a0ee5704..b1def411c0b8 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -512,7 +512,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "PCI INT %c disabled\n", pin_name(pin));
 	if (gsi >= 0) {
 		acpi_unregister_gsi(gsi);
-		dev->irq = 0;
 		dev->irq_managed = 0;
 	}
 }
-- 
1.7.10.4

[Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

[Jiang Liu]

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
---
 arch/x86/include/asm/acpi.h |    1 +
 arch/x86/pci/xen.c          |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 0ab4f9fd2687..3a45668f6dc3 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -50,6 +50,7 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
 
 extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
 				  int trigger, int polarity);
+extern void (*__acpi_unregister_gsi)(u32 gsi);
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c3c644..9098d880c476 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -458,6 +458,7 @@ int __init pci_xen_hvm_init(void)
 	 * just how GSIs get registered.
 	 */
 	__acpi_register_gsi = acpi_register_gsi_xen_hvm;
+	__acpi_unregister_gsi = NULL;
 #endif
 
 #ifdef CONFIG_PCI_MSI
@@ -482,6 +483,7 @@ int __init pci_xen_initial_domain(void)
 	pci_msi_ignore_mask = 1;
 #endif
 	__acpi_register_gsi = acpi_register_gsi_xen;
+	__acpi_unregister_gsi = NULL;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
 		int trigger, polarity;
-- 
1.7.10.4

[Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

[Jiang Liu]

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
---
 arch/x86/include/asm/acpi.h |    1 +
 arch/x86/pci/xen.c          |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 0ab4f9fd2687..3a45668f6dc3 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -50,6 +50,7 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
 
 extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
 				  int trigger, int polarity);
+extern void (*__acpi_unregister_gsi)(u32 gsi);
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c3c644..9098d880c476 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -458,6 +458,7 @@ int __init pci_xen_hvm_init(void)
 	 * just how GSIs get registered.
 	 */
 	__acpi_register_gsi = acpi_register_gsi_xen_hvm;
+	__acpi_unregister_gsi = NULL;
 #endif
 
 #ifdef CONFIG_PCI_MSI
@@ -482,6 +483,7 @@ int __init pci_xen_initial_domain(void)
 	pci_msi_ignore_mask = 1;
 #endif
 	__acpi_register_gsi = acpi_register_gsi_xen;
+	__acpi_unregister_gsi = NULL;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
 		int trigger, polarity;
-- 
1.7.10.4

Re: [Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()

[David Vrabel]

On 20/01/15 02:21, Jiang Liu wrote:
> Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
> that is initialize irq for ACPI SCI at early stage in a special way as:
> xen_init_IRQ()
> 	->pci_xen_initial_domain()
> 		->xen_setup_acpi_sci()
> 			Allocate and initialize irq for ACPI SCI
> 
> Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
> number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
> IOAPIC irqdomains through following path
> acpi_gsi_to_irq()
> 	->mp_map_gsi_to_irq()
> 		->mp_map_pin_to_irq()
> 			->check IOAPIC irqdomain

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Thanks.

David

Re: [Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()

[David Vrabel]

On 20/01/15 02:21, Jiang Liu wrote:
> Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
> that is initialize irq for ACPI SCI at early stage in a special way as:
> xen_init_IRQ()
> 	->pci_xen_initial_domain()
> 		->xen_setup_acpi_sci()
> 			Allocate and initialize irq for ACPI SCI
> 
> Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
> number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
> IOAPIC irqdomains through following path
> acpi_gsi_to_irq()
> 	->mp_map_gsi_to_irq()
> 		->mp_map_pin_to_irq()
> 			->check IOAPIC irqdomain

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Thanks.

David

Re: [Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()

[David Vrabel]

On 20/01/15 02:21, Jiang Liu wrote:
> Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
> that is initialize irq for ACPI SCI at early stage in a special way as:
> xen_init_IRQ()
> 	->pci_xen_initial_domain()
> 		->xen_setup_acpi_sci()
> 			Allocate and initialize irq for ACPI SCI
> 
> Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
> number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
> IOAPIC irqdomains through following path
> acpi_gsi_to_irq()
> 	->mp_map_gsi_to_irq()
> 		->mp_map_pin_to_irq()
> 			->check IOAPIC irqdomain

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Thanks.

David

Re: [Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

[David Vrabel]

On 20/01/15 02:21, Jiang Liu wrote:
> Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
> That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
> acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
> which may cause undesired effects. So override __acpi_unregister_gsi to
> NULL for safety.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Thanks.

David

Re: [Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

[David Vrabel]

On 20/01/15 02:21, Jiang Liu wrote:
> Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
> That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
> acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
> which may cause undesired effects. So override __acpi_unregister_gsi to
> NULL for safety.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

Thanks.

David

[tip:x86/urgent] x86/xen: Treat SCI interrupt as normal GSI interrupt

[tip-bot for Jiang Liu]

Commit-ID:  b568b8601f05a591a7ff09d8ee1cedb5b2e815fe
Gitweb:     http://git.kernel.org/tip/b568b8601f05a591a7ff09d8ee1cedb5b2e815fe
Author:     Jiang Liu <jiang.liu@linux.intel.com>
AuthorDate: Tue, 20 Jan 2015 10:21:05 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 20 Jan 2015 11:44:40 +0100

x86/xen: Treat SCI interrupt as normal GSI interrupt

Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
that is initialize irq for ACPI SCI at early stage in a special way as:
xen_init_IRQ()
	->pci_xen_initial_domain()
		->xen_setup_acpi_sci()
			Allocate and initialize irq for ACPI SCI

Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
IOAPIC irqdomains through following path
acpi_gsi_to_irq()
	->mp_map_gsi_to_irq()
		->mp_map_pin_to_irq()
			->check IOAPIC irqdomain

For PV domains, it uses Xen event based interrupt manangement and
doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
This causes Xen domain0 fail to install interrupt handler for ACPI SCI
and all ACPI events will be lost. Please refer to:
https://lkml.org/lkml/2014/12/19/178

So the fix is to get rid of special treatment for ACPI SCI, just treat
ACPI SCI as normal GSI interrupt as:
acpi_gsi_to_irq()
	->acpi_register_gsi()
		->acpi_register_gsi_xen()
			->xen_register_gsi()

With above change, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/acpi/boot.c | 26 ++++++++++++-------------
 arch/x86/pci/xen.c          | 47 ---------------------------------------------
 2 files changed, 13 insertions(+), 60 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index d162636..b9e30da 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -611,20 +611,20 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
 
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-	int irq;
-
-	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
-		*irqp = gsi;
-	} else {
-		mutex_lock(&acpi_ioapic_lock);
-		irq = mp_map_gsi_to_irq(gsi,
-					IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
-		mutex_unlock(&acpi_ioapic_lock);
-		if (irq < 0)
-			return -1;
-		*irqp = irq;
+	int rc, irq, trigger, polarity;
+
+	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
+	if (rc == 0) {
+		trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+		polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+		irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+		if (irq >= 0) {
+			*irqp = irq;
+			return 0;
+		}
 	}
-	return 0;
+
+	return -1;
 }
 EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index c489ef2..6e5e89c 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -471,52 +471,6 @@ int __init pci_xen_hvm_init(void)
 }
 
 #ifdef CONFIG_XEN_DOM0
-static __init void xen_setup_acpi_sci(void)
-{
-	int rc;
-	int trigger, polarity;
-	int gsi = acpi_sci_override_gsi;
-	int irq = -1;
-	int gsi_override = -1;
-
-	if (!gsi)
-		return;
-
-	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
-	if (rc) {
-		printk(KERN_WARNING "xen: acpi_get_override_irq failed for acpi"
-				" sci, rc=%d\n", rc);
-		return;
-	}
-	trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
-	polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
-
-	printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
-			"polarity=%d\n", gsi, trigger, polarity);
-
-	/* Before we bind the GSI to a Linux IRQ, check whether
-	 * we need to override it with bus_irq (IRQ) value. Usually for
-	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-	 * but there are oddballs where the IRQ != GSI:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-	 * which ends up being: gsi_to_irq[9] == 20
-	 * (which is what acpi_gsi_to_irq ends up calling when starting the
-	 * the ACPI interpreter and keels over since IRQ 9 has not been
-	 * setup as we had setup IRQ 20 for it).
-	 */
-	if (acpi_gsi_to_irq(gsi, &irq) == 0) {
-		/* Use the provided value if it's valid. */
-		if (irq >= 0)
-			gsi_override = irq;
-	}
-
-	gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
-	printk(KERN_INFO "xen: acpi sci %d\n", gsi);
-
-	return;
-}
-
 int __init pci_xen_initial_domain(void)
 {
 	int irq;
@@ -527,7 +481,6 @@ int __init pci_xen_initial_domain(void)
 	x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
 	pci_msi_ignore_mask = 1;
 #endif
-	xen_setup_acpi_sci();
 	__acpi_register_gsi = acpi_register_gsi_xen;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {

[tip:x86/urgent] ACPI: pci: Do not clear pci_dev-> irq in acpi_pci_irq_disable()

[tip-bot for Jiang Liu]

Commit-ID:  9889eaeb7c999cae64006bb98c47f40f412ec875
Gitweb:     http://git.kernel.org/tip/9889eaeb7c999cae64006bb98c47f40f412ec875
Author:     Jiang Liu <jiang.liu@linux.intel.com>
AuthorDate: Tue, 20 Jan 2015 10:21:06 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 20 Jan 2015 11:44:40 +0100

ACPI: pci: Do not clear pci_dev->irq in acpi_pci_irq_disable()

Xen pciback driver assumes that pci_dev->irq won't change after calling
pci_disable_device(). But commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687
("x86, irq: Keep balance of IOAPIC pin reference count") frees irq
resources and resets pci_dev->irq to zero when pci_disable_device() is
called.

So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and
another proper fix will be prepared for next merging window.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1421720467-7709-3-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/acpi/pci_irq.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 5277a0e..b1def41 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -512,7 +512,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "PCI INT %c disabled\n", pin_name(pin));
 	if (gsi >= 0) {
 		acpi_unregister_gsi(gsi);
-		dev->irq = 0;
 		dev->irq_managed = 0;
 	}
 }

[tip:x86/urgent] x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

[tip-bot for Jiang Liu]

Commit-ID:  8abb850a03a3a8b11a0e92949e5b99d9cc178e35
Gitweb:     http://git.kernel.org/tip/8abb850a03a3a8b11a0e92949e5b99d9cc178e35
Author:     Jiang Liu <jiang.liu@linux.intel.com>
AuthorDate: Tue, 20 Jan 2015 10:21:07 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 20 Jan 2015 11:44:41 +0100

x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Graeme Gregory <graeme.gregory@linaro.org>
Cc: Lv Zheng <lv.zheng@intel.com>
Link: http://lkml.kernel.org/r/1421720467-7709-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/acpi.h | 1 +
 arch/x86/pci/xen.c          | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 0ab4f9f..3a45668 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -50,6 +50,7 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
 
 extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
 				  int trigger, int polarity);
+extern void (*__acpi_unregister_gsi)(u32 gsi);
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c..9098d88 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -458,6 +458,7 @@ int __init pci_xen_hvm_init(void)
 	 * just how GSIs get registered.
 	 */
 	__acpi_register_gsi = acpi_register_gsi_xen_hvm;
+	__acpi_unregister_gsi = NULL;
 #endif
 
 #ifdef CONFIG_PCI_MSI
@@ -482,6 +483,7 @@ int __init pci_xen_initial_domain(void)
 	pci_msi_ignore_mask = 1;
 #endif
 	__acpi_register_gsi = acpi_register_gsi_xen;
+	__acpi_unregister_gsi = NULL;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
 		int trigger, polarity;

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Sander Eikelenboom]

Tuesday, January 20, 2015, 3:21:04 AM, you wrote:

> Hi Thomas,
>         This patch set includes three hotfixes related Xen IRQ for v3.19.
> Sorry for the long delay to get these two regressions fixed, it really
> cost me some time to read and understand Xen IRQ code.

> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
> too once it reaches the mainstream kernel.

> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
> It's a temporary solution, I will send the formal fix for v3.20 and
> it has passed tests too.

> Patch 3 fixes an issue found when reading code. There's no real bug
> reports related to this issue yet.

> Great thanks to Konrad and Sander for testing fixes for these regressions.

> Regards,
> Gerry

Hi Gerry,

Since these patches now are: tested, reviewed and have landed into mainline,
could you also provide the backports for 3.17 and 3.18 where required ?

The number of people running into these (subtle) issues with these stable
kernels seems to be steadily increasing.

--
Sander

> Jiang Liu (3):
>   xen/pci: Kill function xen_setup_acpi_sci()
>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>     cffe0a2b5a34
>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

>  arch/x86/include/asm/acpi.h |    1 +
>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>  drivers/acpi/pci_irq.c      |    1 -
>  4 files changed, 16 insertions(+), 61 deletions(-)

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 2143 bytes --]

On 05.02.2015 21:07, Sander Eikelenboom wrote:
> 
> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
> 
>> Hi Thomas,
>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>> Sorry for the long delay to get these two regressions fixed, it really
>> cost me some time to read and understand Xen IRQ code.
> 
>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>> too once it reaches the mainstream kernel.
> 
>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>> It's a temporary solution, I will send the formal fix for v3.20 and
>> it has passed tests too.
> 
>> Patch 3 fixes an issue found when reading code. There's no real bug
>> reports related to this issue yet.
> 
>> Great thanks to Konrad and Sander for testing fixes for these regressions.
> 
>> Regards,
>> Gerry
> 
> Hi Gerry,
> 
> Since these patches now are: tested, reviewed and have landed into mainline,
> could you also provide the backports for 3.17 and 3.18 where required ?

This would be my attempt of backporting those to 3.18 (I have not tried whether
they would apply to 3.17 as well). Those seem to work when test-booting and
Sander said he will give them a try as well. But better check yourself I did not
mess anything up while backporting. One of the three patches seemed not to be
required at all.

-Stefan

> 
> The number of people running into these (subtle) issues with these stable
> kernels seems to be steadily increasing.
> 
> --
> Sander
> 
>> Jiang Liu (3):
>>   xen/pci: Kill function xen_setup_acpi_sci()
>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>     cffe0a2b5a34
>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
> 
>>  arch/x86/include/asm/acpi.h |    1 +
>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>  drivers/acpi/pci_irq.c      |    1 -
>>  4 files changed, 16 insertions(+), 61 deletions(-)
> 
> 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-x86-xen-Treat-SCI-interrupt-as-normal-GSI-interrupt.patch --]
[-- Type: text/x-diff; name="0001-x86-xen-Treat-SCI-interrupt-as-normal-GSI-interrupt.patch", Size: 5360 bytes --]

From 8b5b328b62248d95743ca9af7aa71c06dd808dfe Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang.liu@linux.intel.com>
Date: Tue, 20 Jan 2015 10:21:05 +0800
Subject: [PATCH 1/2] x86/xen: Treat SCI interrupt as normal GSI interrupt

Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
that is initialize irq for ACPI SCI at early stage in a special way as:
xen_init_IRQ()
	->pci_xen_initial_domain()
		->xen_setup_acpi_sci()
			Allocate and initialize irq for ACPI SCI

Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
IOAPIC irqdomains through following path
acpi_gsi_to_irq()
	->mp_map_gsi_to_irq()
		->mp_map_pin_to_irq()
			->check IOAPIC irqdomain

For PV domains, it uses Xen event based interrupt manangement and
doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
This causes Xen domain0 fail to install interrupt handler for ACPI SCI
and all ACPI events will be lost. Please refer to:
https://lkml.org/lkml/2014/12/19/178

So the fix is to get rid of special treatment for ACPI SCI, just treat
ACPI SCI as normal GSI interrupt as:
acpi_gsi_to_irq()
	->acpi_register_gsi()
		->acpi_register_gsi_xen()
			->xen_register_gsi()

With above change, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/kernel/acpi/boot.c | 23 +++++++++++-----------
 arch/x86/pci/xen.c          | 47 ---------------------------------------------
 2 files changed, 12 insertions(+), 58 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index a142e77..460f498 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -604,18 +604,19 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
 
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-	int irq;
-
-	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
-		*irqp = gsi;
-	} else {
-		irq = mp_map_gsi_to_irq(gsi,
-					IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
-		if (irq < 0)
-			return -1;
-		*irqp = irq;
+	int rc, irq, trigger, polarity;
+
+	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
+	if (rc == 0) {
+		trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
+		polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
+		irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+		if (irq >= 0) {
+			*irqp = irq;
+			return 0;
+		}
 	}
-	return 0;
+	return -1;
 }
 EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4..6b3cf7c 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -452,52 +452,6 @@ int __init pci_xen_hvm_init(void)
 }
 
 #ifdef CONFIG_XEN_DOM0
-static __init void xen_setup_acpi_sci(void)
-{
-	int rc;
-	int trigger, polarity;
-	int gsi = acpi_sci_override_gsi;
-	int irq = -1;
-	int gsi_override = -1;
-
-	if (!gsi)
-		return;
-
-	rc = acpi_get_override_irq(gsi, &trigger, &polarity);
-	if (rc) {
-		printk(KERN_WARNING "xen: acpi_get_override_irq failed for acpi"
-				" sci, rc=%d\n", rc);
-		return;
-	}
-	trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
-	polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
-
-	printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
-			"polarity=%d\n", gsi, trigger, polarity);
-
-	/* Before we bind the GSI to a Linux IRQ, check whether
-	 * we need to override it with bus_irq (IRQ) value. Usually for
-	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-	 * but there are oddballs where the IRQ != GSI:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-	 * which ends up being: gsi_to_irq[9] == 20
-	 * (which is what acpi_gsi_to_irq ends up calling when starting the
-	 * the ACPI interpreter and keels over since IRQ 9 has not been
-	 * setup as we had setup IRQ 20 for it).
-	 */
-	if (acpi_gsi_to_irq(gsi, &irq) == 0) {
-		/* Use the provided value if it's valid. */
-		if (irq >= 0)
-			gsi_override = irq;
-	}
-
-	gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
-	printk(KERN_INFO "xen: acpi sci %d\n", gsi);
-
-	return;
-}
-
 int __init pci_xen_initial_domain(void)
 {
 	int irq;
@@ -509,7 +463,6 @@ int __init pci_xen_initial_domain(void)
 	x86_msi.msi_mask_irq = xen_nop_msi_mask_irq;
 	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
 #endif
-	xen_setup_acpi_sci();
 	__acpi_register_gsi = acpi_register_gsi_xen;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
-- 
1.9.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: 0002-x86-xen-Override-ACPI-IRQ-management-callback-__acpi.patch --]
[-- Type: text/x-diff; name="0002-x86-xen-Override-ACPI-IRQ-management-callback-__acpi.patch", Size: 2397 bytes --]

From 96f1d05b484334ff01ea2ee2b66798e294e34d96 Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang.liu@linux.intel.com>
Date: Tue, 20 Jan 2015 10:21:07 +0800
Subject: [PATCH 2/2] x86/xen: Override ACPI IRQ management callback
 __acpi_unregister_gsi

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Graeme Gregory <graeme.gregory@linaro.org>
Cc: Lv Zheng <lv.zheng@intel.com>
Link: http://lkml.kernel.org/r/1421720467-7709-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/include/asm/acpi.h | 1 +
 arch/x86/pci/xen.c          | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 0ab4f9f..3a45668 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -50,6 +50,7 @@ void acpi_pic_sci_set_trigger(unsigned int, u16);
 
 extern int (*__acpi_register_gsi)(struct device *dev, u32 gsi,
 				  int trigger, int polarity);
+extern void (*__acpi_unregister_gsi)(u32 gsi);
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6b3cf7c..3c41716 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -442,6 +442,7 @@ int __init pci_xen_hvm_init(void)
 	 * just how GSIs get registered.
 	 */
 	__acpi_register_gsi = acpi_register_gsi_xen_hvm;
+	__acpi_unregister_gsi = NULL;
 #endif
 
 #ifdef CONFIG_PCI_MSI
@@ -464,6 +465,7 @@ int __init pci_xen_initial_domain(void)
 	x86_msi.msix_mask_irq = xen_nop_msix_mask_irq;
 #endif
 	__acpi_register_gsi = acpi_register_gsi_xen;
+	__acpi_unregister_gsi = NULL;
 	/* Pre-allocate legacy irqs */
 	for (irq = 0; irq < nr_legacy_irqs(); irq++) {
 		int trigger, polarity;
-- 
1.9.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Jiang Liu]

On 2015/2/9 17:47, Stefan Bader wrote:
> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>
>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>
>>> Hi Thomas,
>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>> Sorry for the long delay to get these two regressions fixed, it really
>>> cost me some time to read and understand Xen IRQ code.
>>
>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>> too once it reaches the mainstream kernel.
>>
>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>> it has passed tests too.
>>
>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>> reports related to this issue yet.
>>
>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>
>>> Regards,
>>> Gerry
>>
>> Hi Gerry,
>>
>> Since these patches now are: tested, reviewed and have landed into mainline,
>> could you also provide the backports for 3.17 and 3.18 where required ?
> 
> This would be my attempt of backporting those to 3.18 (I have not tried whether
> they would apply to 3.17 as well). Those seem to work when test-booting and
> Sander said he will give them a try as well. But better check yourself I did not
> mess anything up while backporting. One of the three patches seemed not to be
> required at all.
I'm backporting them too, but now I will give up my patches:)

The first one is a must, which should be applied to 3.17 and 3.18.
The second one doesn't apply to 3.17 or 3.18.
The third may be applied to v3.17 and v3.18, but it shouldn't be applied
according to the stable-kernel doc because no user reports such a bug yet.
Regards
Gerry
> 
> -Stefan
> 
>>
>> The number of people running into these (subtle) issues with these stable
>> kernels seems to be steadily increasing.
>>
>> --
>> Sander
>>
>>> Jiang Liu (3):
>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>     cffe0a2b5a34
>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>
>>>  arch/x86/include/asm/acpi.h |    1 +
>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>  drivers/acpi/pci_irq.c      |    1 -
>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>
>>
> 

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Sander Eikelenboom]

Monday, February 9, 2015, 10:47:43 AM, you wrote:

> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>> 
>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>> 
>>> Hi Thomas,
>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>> Sorry for the long delay to get these two regressions fixed, it really
>>> cost me some time to read and understand Xen IRQ code.
>> 
>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>> too once it reaches the mainstream kernel.
>> 
>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>> it has passed tests too.
>> 
>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>> reports related to this issue yet.
>> 
>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>> 
>>> Regards,
>>> Gerry
>> 
>> Hi Gerry,
>> 
>> Since these patches now are: tested, reviewed and have landed into mainline,
>> could you also provide the backports for 3.17 and 3.18 where required ?

> This would be my attempt of backporting those to 3.18 (I have not tried whether
> they would apply to 3.17 as well). Those seem to work when test-booting and
> Sander said he will give them a try as well. But better check yourself I did not
> mess anything up while backporting. One of the three patches seemed not to be
> required at all.

> -Stefan

Hi Stefan / Gerry,

Happy to inform you i have tested stefan's backport-patches on Intel and AMD:

- Patches apply cleanly to kernel's 3.18.6 and 3.17.8 and compile.
  (hmm, 3.17 seems to be already EOL according to www.kernel.org ?)
- Fixes the subtle issues i had.

So .. Tested-by: Sander Eikelenboom <linux@eikelenboom.it>

Thanks !

--
Sander

>> 
>> The number of people running into these (subtle) issues with these stable
>> kernels seems to be steadily increasing.
>> 
>> --
>> Sander
>> 
>>> Jiang Liu (3):
>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>     cffe0a2b5a34
>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>> 
>>>  arch/x86/include/asm/acpi.h |    1 +
>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>  drivers/acpi/pci_irq.c      |    1 -
>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>> 
>> 

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Stefan Bader]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

On 09.02.2015 13:12, Jiang Liu wrote:
> On 2015/2/9 17:47, Stefan Bader wrote:
>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>
>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>
>>>> Hi Thomas,
>>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>>> Sorry for the long delay to get these two regressions fixed, it really
>>>> cost me some time to read and understand Xen IRQ code.
>>>
>>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>>> too once it reaches the mainstream kernel.
>>>
>>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>>> it has passed tests too.
>>>
>>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>>> reports related to this issue yet.
>>>
>>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>>
>>>> Regards,
>>>> Gerry
>>>
>>> Hi Gerry,
>>>
>>> Since these patches now are: tested, reviewed and have landed into mainline,
>>> could you also provide the backports for 3.17 and 3.18 where required ?
>>
>> This would be my attempt of backporting those to 3.18 (I have not tried whether
>> they would apply to 3.17 as well). Those seem to work when test-booting and
>> Sander said he will give them a try as well. But better check yourself I did not
>> mess anything up while backporting. One of the three patches seemed not to be
>> required at all.
> I'm backporting them too, but now I will give up my patches:)
> 
> The first one is a must, which should be applied to 3.17 and 3.18.
> The second one doesn't apply to 3.17 or 3.18.
> The third may be applied to v3.17 and v3.18, but it shouldn't be applied
> according to the stable-kernel doc because no user reports such a bug yet.

Hm, ok. So maybe I should retry with only patch#1 and verify that alone gets
around the acpi irq and the usb problems, too. Though interestingly from the
history, the acpi irq I saw in 3.17 while the usb devices started to fail with
3.18. I will let you know in a bit. Just want to finish another bisect first.

-Stefan

> Regards
> Gerry
>>
>> -Stefan
>>
>>>
>>> The number of people running into these (subtle) issues with these stable
>>> kernels seems to be steadily increasing.
>>>
>>> --
>>> Sander
>>>
>>>> Jiang Liu (3):
>>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>>     cffe0a2b5a34
>>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>>
>>>>  arch/x86/include/asm/acpi.h |    1 +
>>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>>  drivers/acpi/pci_irq.c      |    1 -
>>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>>
>>>
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Stefan Bader]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

On 09.02.2015 13:29, Stefan Bader wrote:
> On 09.02.2015 13:12, Jiang Liu wrote:
>> On 2015/2/9 17:47, Stefan Bader wrote:
>>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>>
>>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>>
>>>>> Hi Thomas,
>>>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>>>> Sorry for the long delay to get these two regressions fixed, it really
>>>>> cost me some time to read and understand Xen IRQ code.
>>>>
>>>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>>>> too once it reaches the mainstream kernel.
>>>>
>>>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>>>> it has passed tests too.
>>>>
>>>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>>>> reports related to this issue yet.
>>>>
>>>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>>>
>>>>> Regards,
>>>>> Gerry
>>>>
>>>> Hi Gerry,
>>>>
>>>> Since these patches now are: tested, reviewed and have landed into mainline,
>>>> could you also provide the backports for 3.17 and 3.18 where required ?
>>>
>>> This would be my attempt of backporting those to 3.18 (I have not tried whether
>>> they would apply to 3.17 as well). Those seem to work when test-booting and
>>> Sander said he will give them a try as well. But better check yourself I did not
>>> mess anything up while backporting. One of the three patches seemed not to be
>>> required at all.
>> I'm backporting them too, but now I will give up my patches:)
>>
>> The first one is a must, which should be applied to 3.17 and 3.18.
>> The second one doesn't apply to 3.17 or 3.18.
>> The third may be applied to v3.17 and v3.18, but it shouldn't be applied
>> according to the stable-kernel doc because no user reports such a bug yet.
> 
> Hm, ok. So maybe I should retry with only patch#1 and verify that alone gets
> around the acpi irq and the usb problems, too. Though interestingly from the
> history, the acpi irq I saw in 3.17 while the usb devices started to fail with
> 3.18. I will let you know in a bit. Just want to finish another bisect first.

So it looks like patch #1 indeed does fix both the acpi irq and my usb devices.
Sander, do you want to verify that variant, too?

The only odd thing left in a 3.18 with the fix (regardless of using patch #1
only or patches #1 and #3) is that the ahci driver shows up with its pci bus
number in /proc/interrupts. But that does not seem to have any relevant downside
(cannot try 3.19 on that box right now for other reasons).

-Stefan

...
# 57: 12441  0    0    0  xen-pirq-msi       0000:00:1f.2
#                                            (used to be ahci)

> 
> -Stefan
> 
>> Regards
>> Gerry
>>>
>>> -Stefan
>>>
>>>>
>>>> The number of people running into these (subtle) issues with these stable
>>>> kernels seems to be steadily increasing.
>>>>
>>>> --
>>>> Sander
>>>>
>>>>> Jiang Liu (3):
>>>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>>>     cffe0a2b5a34
>>>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>>>
>>>>>  arch/x86/include/asm/acpi.h |    1 +
>>>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>>>  drivers/acpi/pci_irq.c      |    1 -
>>>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>>>
>>>>
>>>
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Sander Eikelenboom]

Monday, February 9, 2015, 5:09:44 PM, you wrote:

> On 09.02.2015 13:29, Stefan Bader wrote:
>> On 09.02.2015 13:12, Jiang Liu wrote:
>>> On 2015/2/9 17:47, Stefan Bader wrote:
>>>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>>>
>>>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>>>
>>>>>> Hi Thomas,
>>>>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>>>>> Sorry for the long delay to get these two regressions fixed, it really
>>>>>> cost me some time to read and understand Xen IRQ code.
>>>>>
>>>>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>>>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>>>>> too once it reaches the mainstream kernel.
>>>>>
>>>>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>>>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>>>>> it has passed tests too.
>>>>>
>>>>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>>>>> reports related to this issue yet.
>>>>>
>>>>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>>>>
>>>>>> Regards,
>>>>>> Gerry
>>>>>
>>>>> Hi Gerry,
>>>>>
>>>>> Since these patches now are: tested, reviewed and have landed into mainline,
>>>>> could you also provide the backports for 3.17 and 3.18 where required ?
>>>>
>>>> This would be my attempt of backporting those to 3.18 (I have not tried whether
>>>> they would apply to 3.17 as well). Those seem to work when test-booting and
>>>> Sander said he will give them a try as well. But better check yourself I did not
>>>> mess anything up while backporting. One of the three patches seemed not to be
>>>> required at all.
>>> I'm backporting them too, but now I will give up my patches:)
>>>
>>> The first one is a must, which should be applied to 3.17 and 3.18.
>>> The second one doesn't apply to 3.17 or 3.18.
>>> The third may be applied to v3.17 and v3.18, but it shouldn't be applied
>>> according to the stable-kernel doc because no user reports such a bug yet.
>> 
>> Hm, ok. So maybe I should retry with only patch#1 and verify that alone gets
>> around the acpi irq and the usb problems, too. Though interestingly from the
>> history, the acpi irq I saw in 3.17 while the usb devices started to fail with
>> 3.18. I will let you know in a bit. Just want to finish another bisect first.

> So it looks like patch #1 indeed does fix both the acpi irq and my usb devices.
> Sander, do you want to verify that variant, too?

Will test 3.18 with only patch 1 after dinner.

> The only odd thing left in a 3.18 with the fix (regardless of using patch #1
> only or patches #1 and #3) is that the ahci driver shows up with its pci bus
> number in /proc/interrupts. But that does not seem to have any relevant downside
> (cannot try 3.19 on that box right now for other reasons).

> -Stefan

> ...
> # 57: 12441  0    0    0  xen-pirq-msi       0000:00:1f.2
> #                                            (used to be ahci)

Hmm funky .. now that you mention it .. i'm seeing that as well but only on an 
intel machine.

intel .. on 3.19:
 52:      13529          0          0          0  xen-pirq-msi       0000:00:1f.2
 
on my amd machine on 3.19 it seems ok though:

 114:     412535          0          0          0          0          0  xen-pirq-msi       ahci0
 115:          0          0          0          0          0          0  xen-pirq-msi       ahci1
 116:      16717          0          0          0          0          0  xen-pirq-msi       ahci2
 117:          0          0          0          0          0          0  xen-pirq-msi       ahci3
 118:          0          0          0          0          0          0  xen-pirq-msi       ahci4
 119:          0          0          0          0          0          0  xen-pirq-msi       ahci5

--
Sander

>> 
>> -Stefan
>> 
>>> Regards
>>> Gerry
>>>>
>>>> -Stefan
>>>>
>>>>>
>>>>> The number of people running into these (subtle) issues with these stable
>>>>> kernels seems to be steadily increasing.
>>>>>
>>>>> --
>>>>> Sander
>>>>>
>>>>>> Jiang Liu (3):
>>>>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>>>>     cffe0a2b5a34
>>>>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>>>>
>>>>>>  arch/x86/include/asm/acpi.h |    1 +
>>>>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>>>>  drivers/acpi/pci_irq.c      |    1 -
>>>>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>>>>
>>>>>
>>>>
>> 
>> 

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Sander Eikelenboom]

Monday, February 9, 2015, 5:09:44 PM, you wrote:

> On 09.02.2015 13:29, Stefan Bader wrote:
>> On 09.02.2015 13:12, Jiang Liu wrote:
>>> On 2015/2/9 17:47, Stefan Bader wrote:
>>>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>>>
>>>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>>>
>>>>>> Hi Thomas,
>>>>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>>>>> Sorry for the long delay to get these two regressions fixed, it really
>>>>>> cost me some time to read and understand Xen IRQ code.
>>>>>
>>>>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>>>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>>>>> too once it reaches the mainstream kernel.
>>>>>
>>>>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>>>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>>>>> it has passed tests too.
>>>>>
>>>>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>>>>> reports related to this issue yet.
>>>>>
>>>>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>>>>
>>>>>> Regards,
>>>>>> Gerry
>>>>>
>>>>> Hi Gerry,
>>>>>
>>>>> Since these patches now are: tested, reviewed and have landed into mainline,
>>>>> could you also provide the backports for 3.17 and 3.18 where required ?
>>>>
>>>> This would be my attempt of backporting those to 3.18 (I have not tried whether
>>>> they would apply to 3.17 as well). Those seem to work when test-booting and
>>>> Sander said he will give them a try as well. But better check yourself I did not
>>>> mess anything up while backporting. One of the three patches seemed not to be
>>>> required at all.
>>> I'm backporting them too, but now I will give up my patches:)
>>>
>>> The first one is a must, which should be applied to 3.17 and 3.18.
>>> The second one doesn't apply to 3.17 or 3.18.
>>> The third may be applied to v3.17 and v3.18, but it shouldn't be applied
>>> according to the stable-kernel doc because no user reports such a bug yet.
>> 
>> Hm, ok. So maybe I should retry with only patch#1 and verify that alone gets
>> around the acpi irq and the usb problems, too. Though interestingly from the
>> history, the acpi irq I saw in 3.17 while the usb devices started to fail with
>> 3.18. I will let you know in a bit. Just want to finish another bisect first.

> So it looks like patch #1 indeed does fix both the acpi irq and my usb devices.
> Sander, do you want to verify that variant, too?

Hi Stefan / Gerry,

Just tested with only patch 1, ended up the same .. the reported issues seem 
gone.


> The only odd thing left in a 3.18 with the fix (regardless of using patch #1
> only or patches #1 and #3) is that the ahci driver shows up with its pci bus
> number in /proc/interrupts. But that does not seem to have any relevant downside
> (cannot try 3.19 on that box right now for other reasons).

> -Stefan

> ...
> # 57: 12441  0    0    0  xen-pirq-msi       0000:00:1f.2
> #                                            (used to be ahci)

This is also there on baremetal with 3.19 on intel, so not xen related:
 27:       1868        582       1282        555  IR-PCI-MSI-edge      0000:00:1f.2

--
Sander

>> 
>> -Stefan
>> 
>>> Regards
>>> Gerry
>>>>
>>>> -Stefan
>>>>
>>>>>
>>>>> The number of people running into these (subtle) issues with these stable
>>>>> kernels seems to be steadily increasing.
>>>>>
>>>>> --
>>>>> Sander
>>>>>
>>>>>> Jiang Liu (3):
>>>>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>>>>     cffe0a2b5a34
>>>>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>>>>
>>>>>>  arch/x86/include/asm/acpi.h |    1 +
>>>>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>>>>  drivers/acpi/pci_irq.c      |    1 -
>>>>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>>>>
>>>>>
>>>>
>> 
>> 

Re: [Bugfix 0/3] Xen IRQ related hotfixes for v3.19

[Stefan Bader]

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

On 09.02.2015 20:15, Sander Eikelenboom wrote:
> 
> Monday, February 9, 2015, 5:09:44 PM, you wrote:
> 
>> On 09.02.2015 13:29, Stefan Bader wrote:
>>> On 09.02.2015 13:12, Jiang Liu wrote:
>>>> On 2015/2/9 17:47, Stefan Bader wrote:
>>>>> On 05.02.2015 21:07, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Tuesday, January 20, 2015, 3:21:04 AM, you wrote:
>>>>>>
>>>>>>> Hi Thomas,
>>>>>>>         This patch set includes three hotfixes related Xen IRQ for v3.19.
>>>>>>> Sorry for the long delay to get these two regressions fixed, it really
>>>>>>> cost me some time to read and understand Xen IRQ code.
>>>>>>
>>>>>>> Patch 1 fixes the failure to register ACPI SCI interrupt on Xen
>>>>>>> domain0 by reworking acpi_gsi_to_irq(). I will backport it to v3.18
>>>>>>> too once it reaches the mainstream kernel.
>>>>>>
>>>>>>> Patch 2 fixes the regression in Xen PCI device passthrough(pciback).
>>>>>>> It's a temporary solution, I will send the formal fix for v3.20 and
>>>>>>> it has passed tests too.
>>>>>>
>>>>>>> Patch 3 fixes an issue found when reading code. There's no real bug
>>>>>>> reports related to this issue yet.
>>>>>>
>>>>>>> Great thanks to Konrad and Sander for testing fixes for these regressions.
>>>>>>
>>>>>>> Regards,
>>>>>>> Gerry
>>>>>>
>>>>>> Hi Gerry,
>>>>>>
>>>>>> Since these patches now are: tested, reviewed and have landed into mainline,
>>>>>> could you also provide the backports for 3.17 and 3.18 where required ?
>>>>>
>>>>> This would be my attempt of backporting those to 3.18 (I have not tried whether
>>>>> they would apply to 3.17 as well). Those seem to work when test-booting and
>>>>> Sander said he will give them a try as well. But better check yourself I did not
>>>>> mess anything up while backporting. One of the three patches seemed not to be
>>>>> required at all.
>>>> I'm backporting them too, but now I will give up my patches:)
>>>>
>>>> The first one is a must, which should be applied to 3.17 and 3.18.
>>>> The second one doesn't apply to 3.17 or 3.18.
>>>> The third may be applied to v3.17 and v3.18, but it shouldn't be applied
>>>> according to the stable-kernel doc because no user reports such a bug yet.
>>>
>>> Hm, ok. So maybe I should retry with only patch#1 and verify that alone gets
>>> around the acpi irq and the usb problems, too. Though interestingly from the
>>> history, the acpi irq I saw in 3.17 while the usb devices started to fail with
>>> 3.18. I will let you know in a bit. Just want to finish another bisect first.
> 
>> So it looks like patch #1 indeed does fix both the acpi irq and my usb devices.
>> Sander, do you want to verify that variant, too?
> 
> Hi Stefan / Gerry,
> 
> Just tested with only patch 1, ended up the same .. the reported issues seem 
> gone.

Sounds good. :) Gerry, do you want me to fwd the backport to Greg for 3.18 or do
you do that? As far as I know 3.17 has nobody caring about it.

-Stefan

> 
> 
>> The only odd thing left in a 3.18 with the fix (regardless of using patch #1
>> only or patches #1 and #3) is that the ahci driver shows up with its pci bus
>> number in /proc/interrupts. But that does not seem to have any relevant downside
>> (cannot try 3.19 on that box right now for other reasons).
> 
>> -Stefan
> 
>> ...
>> # 57: 12441  0    0    0  xen-pirq-msi       0000:00:1f.2
>> #                                            (used to be ahci)
> 
> This is also there on baremetal with 3.19 on intel, so not xen related:
>  27:       1868        582       1282        555  IR-PCI-MSI-edge      0000:00:1f.2
> 
> --
> Sander
> 
>>>
>>> -Stefan
>>>
>>>> Regards
>>>> Gerry
>>>>>
>>>>> -Stefan
>>>>>
>>>>>>
>>>>>> The number of people running into these (subtle) issues with these stable
>>>>>> kernels seems to be steadily increasing.
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>>>
>>>>>>> Jiang Liu (3):
>>>>>>>   xen/pci: Kill function xen_setup_acpi_sci()
>>>>>>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>>>>>>>     cffe0a2b5a34
>>>>>>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>>>>>
>>>>>>>  arch/x86/include/asm/acpi.h |    1 +
>>>>>>>  arch/x86/kernel/acpi/boot.c |   26 +++++++++++------------
>>>>>>>  arch/x86/pci/xen.c          |   49 ++-----------------------------------------
>>>>>>>  drivers/acpi/pci_irq.c      |    1 -
>>>>>>>  4 files changed, 16 insertions(+), 61 deletions(-)
>>>>>>
>>>>>>
>>>>>
>>>
>>>
> 
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]