Xen IRQ related hotfixes for v3.19
cover Xen IRQ related hotfixes for v3.19
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(-)
Signature · 1 line
1.7.10.4
PATCH 1/3 xen/pci: Kill function xen_setup_acpi_sci()
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.
--- arch/x86/kernel/acpi/boot.c | 26 ++++++++++++------------ arch/x86/pci/xen.c | 47 ------------------------------------------- 2 files changed, 13 insertions(+), 60 deletions(-)
arch/x86/kernel/acpi/boot.c +13 -13
@@ -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);
arch/x86/pci/xen.c +0 -47
59 lines not on this page · raw message
Signature · 1 line
1.7.10.4
Re: [Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()
Quoted 7 lines · 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
Quoted 7 lines
Function
xen_setup_acpi_sci()callsacpi_gsi_to_irq()to get an irq number for ACPI SCI. But unfortunatelyacpi_gsi_to_irq()depends on IOAPIC irqdomains through following pathacpi_gsi_to_irq()->mp_map_gsi_to_irq() ->mp_map_pin_to_irq() ->check IOAPIC irqdomain
Thanks.
David
Re: [Bugfix 1/3] xen/pci: Kill function xen_setup_acpi_sci()
In reply to Jiang LiuQuoted 7 lines · 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
Quoted 7 lines
Function
xen_setup_acpi_sci()callsacpi_gsi_to_irq()to get an irq number for ACPI SCI. But unfortunatelyacpi_gsi_to_irq()depends on IOAPIC irqdomains through following pathacpi_gsi_to_irq()->mp_map_gsi_to_irq() ->mp_map_pin_to_irq() ->check IOAPIC irqdomain
Thanks.
David
tip-bot for Jiang Liu
merge bot[tip:x86/urgent] x86/xen: Treat SCI interrupt as normal GSI interrupt
In reply to Jiang Liux86/xen: Treat SCI interrupt as normal GSI interrupt
Commit-ID: b568b8601f05a591a7ff09d8ee1cedb5b2e815fe Gitweb: http://git.kernel.org/tip/b568b8601f05a591a7ff09d8ee1cedb5b2e815fe Author: Jiang Liu <[email protected]> AuthorDate: Tue, 20 Jan 2015 10:21:05 +0800 Committer: Thomas Gleixner <[email protected]> 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.
--- arch/x86/kernel/acpi/boot.c | 26 ++++++++++++------------- arch/x86/pci/xen.c | 47 --------------------------------------------- 2 files changed, 13 insertions(+), 60 deletions(-)
arch/x86/kernel/acpi/boot.c +13 -13
@@ -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);
arch/x86/pci/xen.c +0 -47
59 lines not on this page · raw message
PATCH 1/3 xen/pci: Kill function xen_setup_acpi_sci()
In reply to Jiang LiuCurrently 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.
--- arch/x86/kernel/acpi/boot.c | 26 ++++++++++++------------ arch/x86/pci/xen.c | 47 ------------------------------------------- 2 files changed, 13 insertions(+), 60 deletions(-)
arch/x86/kernel/acpi/boot.c +13 -13
@@ -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);
arch/x86/pci/xen.c +0 -47
59 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 2/3 xen/irq, ACPI: Fix regression in xen PCI passthrough caused by cffe0a2b5a34
In reply to Jiang LiuXen 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.
--- drivers/acpi/pci_irq.c | 1 - 1 file changed, 1 deletion(-)
drivers/acpi/pci_irq.c +0 -1
@@ -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 ; } }
Signature · 1 line
1.7.10.4
tip-bot for Jiang Liu
merge bot[tip:x86/urgent] ACPI: pci: Do not clear pci_dev-> irq in acpi_pci_irq_disable()
ACPI: pci: Do not clear pci_dev->irq in acpi_pci_irq_disable()
Commit-ID: 9889eaeb7c999cae64006bb98c47f40f412ec875 Gitweb: http://git.kernel.org/tip/9889eaeb7c999cae64006bb98c47f40f412ec875 Author: Jiang Liu <[email protected]> AuthorDate: Tue, 20 Jan 2015 10:21:06 +0800 Committer: Thomas Gleixner <[email protected]> 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.
--- drivers/acpi/pci_irq.c | 1 - 1 file changed, 1 deletion(-)
drivers/acpi/pci_irq.c +0 -1
@@ -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 ; } }
PATCH 3/3 xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
In reply to Jiang LiuXen 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.
--- arch/x86/include/asm/acpi.h | 1 + arch/x86/pci/xen.c | 2 ++ 2 files changed, 3 insertions(+)
arch/x86/include/asm/acpi.h +1 -0
@@ -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 ) {
arch/x86/pci/xen.c +2 -0
@@ -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;
Signature · 1 line
1.7.10.4
Re: [Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
Quoted 5 lines · Jiang Liu
Xen overrides
__acpi_register_gsiand leaves__acpi_unregister_gsias is. That means, an IRQ allocated byacpi_register_gsi_xen_hvm()oracpi_register_gsi_xen()will be freed byacpi_unregister_gsi_ioapic(), which may cause undesired effects. So override__acpi_unregister_gsito NULL for safety.
Thanks.
David
Re: [Bugfix 3/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
In reply to Jiang LiuQuoted 5 lines · Jiang Liu
Xen overrides
__acpi_register_gsiand leaves__acpi_unregister_gsias is. That means, an IRQ allocated byacpi_register_gsi_xen_hvm()oracpi_register_gsi_xen()will be freed byacpi_unregister_gsi_ioapic(), which may cause undesired effects. So override__acpi_unregister_gsito NULL for safety.
Thanks.
David
tip-bot for Jiang Liu
merge bot[tip:x86/urgent] x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi
In reply to Jiang Liux86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi
Commit-ID: 8abb850a03a3a8b11a0e92949e5b99d9cc178e35 Gitweb: http://git.kernel.org/tip/8abb850a03a3a8b11a0e92949e5b99d9cc178e35 Author: Jiang Liu <[email protected]> AuthorDate: Tue, 20 Jan 2015 10:21:07 +0800 Committer: Thomas Gleixner <[email protected]> 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.
--- arch/x86/include/asm/acpi.h | 1 + arch/x86/pci/xen.c | 2 ++ 2 files changed, 3 insertions(+)
arch/x86/include/asm/acpi.h +1 -0
@@ -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 ) {
arch/x86/pci/xen.c +2 -0
@@ -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;
PATCH 3/3 xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
In reply to Jiang LiuXen 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.
--- arch/x86/include/asm/acpi.h | 1 + arch/x86/pci/xen.c | 2 ++ 2 files changed, 3 insertions(+)
arch/x86/include/asm/acpi.h +1 -0
@@ -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 ) {
arch/x86/pci/xen.c +2 -0
@@ -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;
Signature · 1 line
1.7.10.4
Quoted 13 lines · you
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.
Quoted 7 lines
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
Quoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 21 lines · Sander Eikelenboom
Quoted 17 lines · you
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.
Quoted 7 lines
Quoted 2 lines
Regards,
GerryHi 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
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
From 8b5b328b62248d95743ca9af7aa71c06dd808dfe Mon Sep 17 00:00:00 2001
From: Jiang Liu <[email protected]>
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.
--- arch/x86/kernel/acpi/boot.c | 23 +++++++++++----------- arch/x86/pci/xen.c | 47 --------------------------------------------- 2 files changed, 12 insertions(+), 58 deletions(-)
arch/x86/kernel/acpi/boot.c +12 -11
@@ -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);
arch/x86/pci/xen.c +0 -47
59 lines not on this page · raw message
Signature · 1 line
1.9.1
From 96f1d05b484334ff01ea2ee2b66798e294e34d96 Mon Sep 17 00:00:00 2001
From: Jiang Liu <[email protected]>
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.
--- arch/x86/include/asm/acpi.h | 1 + arch/x86/pci/xen.c | 2 ++ 2 files changed, 3 insertions(+)
arch/x86/include/asm/acpi.h +1 -0
@@ -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 ) {
arch/x86/pci/xen.c +2 -0
@@ -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;
Signature · 1 line
1.9.1
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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
Quoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 36 lines · Jiang Liu
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
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
Quoted 26 lines
Regards
GerryQuoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 44 lines · Stefan Bader
Quoted 36 lines · Jiang Liu
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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)
Quoted 31 lines
-Stefan
Quoted 26 lines
Regards
GerryQuoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 45 lines · you
Quoted 44 lines · Stefan Bader
Quoted 42 lines · Jiang Liu
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 10 lines
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
Quoted 31 lines
Quoted 31 lines
-Stefan
Quoted 26 lines
Regards
GerryQuoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 45 lines · you
Quoted 44 lines · Stefan Bader
Quoted 42 lines · Jiang Liu
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 10 lines
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
Quoted 31 lines
Quoted 31 lines
-Stefan
Quoted 26 lines
Regards
GerryQuoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 53 lines · Sander Eikelenboom
Quoted 49 lines · you
Quoted 48 lines · Stefan Bader
Quoted 36 lines · Jiang Liu
Quoted 27 lines · Stefan Bader
Quoted 26 lines · Sander Eikelenboom
Quoted 13 lines · you
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.
Quoted 7 lines
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,
GerryHi Gerry,
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 53 lines
Quoted 7 lines
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).Quoted 5 lines
-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--
SanderQuoted 31 lines
Quoted 31 lines
-Stefan
Quoted 26 lines
Regards
GerryQuoted 24 lines
-Stefan
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)
Quoted 30 lines · you
Quoted 21 lines · Sander Eikelenboom
Quoted 17 lines · you
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.
Quoted 7 lines
Quoted 2 lines
Regards,
GerryHi 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 ?
Quoted 7 lines
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 <[email protected]>
Thanks !
--
Sander
Quoted 20 lines
Quoted 20 lines
The number of people running into these (subtle) issues with these stable kernels seems to be steadily increasing.
--
SanderQuoted 11 lines
Jiang Liu (3):
xen/pci: Kill functionxen_setup_acpi_sci()
xen/irq, ACPI: Fix regression in xen PCI passthrough caused bycffe0a2b5a34xen/irq: Override ACPI IRQ management callback
__acpi_unregister_gsiarch/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(-)