[Xen-devel] [RFC Patch V1 06/12] PCI: Use for_pci_msi_entry() to access MSI device list

2015-07-09 Thread Jiang Liu
Use accessor for_pci_msi_entry() to access MSI device list, so we could easily
move msi_list from struct pci_dev into struct device later.

Signed-off-by: Jiang Liu 
---
 drivers/pci/msi.c  |   39 ---
 drivers/pci/xen-pcifront.c |2 +-
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 7b4c20c9f9ca..d09afa78d7a1 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -131,7 +131,7 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
if (type == PCI_CAP_ID_MSI && nvec > 1)
return 1;
 
-   list_for_each_entry(entry, &dev->msi_list, list) {
+   for_each_pci_msi_entry(entry, dev) {
ret = arch_setup_msi_irq(dev, entry);
if (ret < 0)
return ret;
@@ -151,7 +151,7 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
int i;
struct msi_desc *entry;
 
-   list_for_each_entry(entry, &dev->msi_list, list)
+   for_each_pci_msi_entry(entry, dev)
if (entry->irq)
for (i = 0; i < entry->nvec_used; i++)
arch_teardown_msi_irq(entry->irq + i);
@@ -168,7 +168,7 @@ static void default_restore_msi_irq(struct pci_dev *dev, 
int irq)
 
entry = NULL;
if (dev->msix_enabled) {
-   list_for_each_entry(entry, &dev->msi_list, list) {
+   for_each_pci_msi_entry(entry, dev) {
if (irq == entry->irq)
break;
}
@@ -282,7 +282,7 @@ void default_restore_msi_irqs(struct pci_dev *dev)
 {
struct msi_desc *entry;
 
-   list_for_each_entry(entry, &dev->msi_list, list)
+   for_each_pci_msi_entry(entry, dev)
default_restore_msi_irq(dev, entry->irq);
 }
 
@@ -363,21 +363,22 @@ EXPORT_SYMBOL_GPL(pci_write_msi_msg);
 
 static void free_msi_irqs(struct pci_dev *dev)
 {
+   struct list_head *msi_list = dev_to_msi_list(&dev->dev);
struct msi_desc *entry, *tmp;
struct attribute **msi_attrs;
struct device_attribute *dev_attr;
int i, count = 0;
 
-   list_for_each_entry(entry, &dev->msi_list, list)
+   for_each_pci_msi_entry(entry, dev)
if (entry->irq)
for (i = 0; i < entry->nvec_used; i++)
BUG_ON(irq_has_action(entry->irq + i));
 
pci_msi_teardown_msi_irqs(dev);
 
-   list_for_each_entry_safe(entry, tmp, &dev->msi_list, list) {
+   list_for_each_entry_safe(entry, tmp, msi_list, list) {
if (entry->msi_attrib.is_msix) {
-   if (list_is_last(&entry->list, &dev->msi_list))
+   if (list_is_last(&entry->list, msi_list))
iounmap(entry->mask_base);
}
 
@@ -448,7 +449,7 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
 
if (!dev->msix_enabled)
return;
-   BUG_ON(list_empty(&dev->msi_list));
+   BUG_ON(list_empty(dev_to_msi_list(&dev->dev)));
 
/* route the table */
pci_intx_for_msi(dev, 0);
@@ -456,7 +457,7 @@ static void __pci_restore_msix_state(struct pci_dev *dev)
PCI_MSIX_FLAGS_ENABLE | PCI_MSIX_FLAGS_MASKALL);
 
arch_restore_msi_irqs(dev);
-   list_for_each_entry(entry, &dev->msi_list, list)
+   for_each_pci_msi_entry(entry, dev)
msix_mask_irq(entry, entry->masked);
 
pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
@@ -501,7 +502,7 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
int count = 0;
 
/* Determine how many msi entries we have */
-   list_for_each_entry(entry, &pdev->msi_list, list)
+   for_each_pci_msi_entry(entry, pdev)
++num_msi;
if (!num_msi)
return 0;
@@ -510,7 +511,7 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
msi_attrs = kzalloc(sizeof(void *) * (num_msi + 1), GFP_KERNEL);
if (!msi_attrs)
return -ENOMEM;
-   list_for_each_entry(entry, &pdev->msi_list, list) {
+   for_each_pci_msi_entry(entry, pdev) {
msi_dev_attr = kzalloc(sizeof(*msi_dev_attr), GFP_KERNEL);
if (!msi_dev_attr)
goto error_attrs;
@@ -599,7 +600,7 @@ static int msi_verify_entries(struct pci_dev *dev)
 {
struct msi_desc *entry;
 
-   list_for_each_entry(entry, &dev->msi_list, list) {
+   for_each_pci_msi_entry(entry, dev) {
if (!dev->no_64bit_msi || !entry->msg.address_hi)
continue;
dev_err(&dev->dev, "Device has broken 64-bit 

[Xen-devel] [RFC Patch V1 05/12] x86, PCI: Use for_pci_msi_entry() to access MSI device list

2015-07-09 Thread Jiang Liu
Use accessor for_pci_msi_entry() to access MSI device list, so we could
easily move msi_list from struct pci_dev into struct device later.

Signed-off-by: Jiang Liu 
---
 arch/x86/pci/xen.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index d22f4b5bbc04..ff31ab464213 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -179,7 +179,7 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
if (ret)
goto error;
i = 0;
-   list_for_each_entry(msidesc, &dev->msi_list, list) {
+   for_each_pci_msi_entry(msidesc, dev) {
irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i],
   (type == PCI_CAP_ID_MSI) ? nvec 
: 1,
   (type == PCI_CAP_ID_MSIX) ?
@@ -230,7 +230,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
if (type == PCI_CAP_ID_MSI && nvec > 1)
return 1;
 
-   list_for_each_entry(msidesc, &dev->msi_list, list) {
+   for_each_pci_msi_entry(msidesc, dev) {
__pci_read_msi_msg(msidesc, &msg);
pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
@@ -274,7 +274,7 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, 
int nvec, int type)
int ret = 0;
struct msi_desc *msidesc;
 
-   list_for_each_entry(msidesc, &dev->msi_list, list) {
+   for_each_pci_msi_entry(msidesc, dev) {
struct physdev_map_pirq map_irq;
domid_t domid;
 
@@ -386,7 +386,7 @@ static void xen_teardown_msi_irqs(struct pci_dev *dev)
 {
struct msi_desc *msidesc;
 
-   msidesc = list_entry(dev->msi_list.next, struct msi_desc, list);
+   msidesc = first_pci_msi_entry(dev);
if (msidesc->msi_attrib.is_msix)
xen_pci_frontend_disable_msix(dev);
else
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

2015-06-02 Thread Jiang Liu
Use access helper irq_data_get_affinity_mask() to hide implementation
details of struct irq_desc.

Signed-off-by: Jiang Liu 
---
Hi Thomas,
This version changes the patch to correctly support bisecting.
Thanks!
Gerry
---
 arch/x86/kernel/apic/io_apic.c   |2 +-
 arch/x86/kernel/apic/vector.c|3 ++-
 arch/x86/kernel/irq.c|5 +++--
 drivers/xen/events/events_base.c |4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 845dc0df2002..09921de4210f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2541,7 +2541,7 @@ void __init setup_ioapic_dest(void)
 * Honour affinities which have been set in early boot
 */
if (!irqd_can_balance(idata) || irqd_affinity_was_set(idata))
-   mask = idata->affinity;
+   mask = irq_data_get_affinity_mask(idata);
else
mask = apic->target_cpus();
 
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9b62f690b0ff..7ad911ea4f56 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -496,7 +496,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
if (err) {
struct irq_data *top = irq_get_irq_data(irq);
 
-   if (assign_irq_vector(irq, data, top->affinity))
+   if (assign_irq_vector(irq, data,
+ irq_data_get_affinity_mask(top)))
pr_err("Failed to recover vector for irq %d\n", irq);
return err;
}
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 7e10c8b4b318..37685e37550c 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -342,7 +342,8 @@ int check_irq_vectors_for_cpu_disable(void)
continue;
 
data = irq_desc_get_irq_data(desc);
-   cpumask_copy(&affinity_new, data->affinity);
+   cpumask_copy(&affinity_new,
+irq_data_get_affinity_mask(data));
cpumask_clear_cpu(this_cpu, &affinity_new);
 
/* Do not count inactive or per-cpu irqs. */
@@ -420,7 +421,7 @@ void fixup_irqs(void)
raw_spin_lock(&desc->lock);
 
data = irq_desc_get_irq_data(desc);
-   affinity = data->affinity;
+   affinity = irq_data_get_affinity_mask(data);
if (!irq_has_action(irq) || irqd_is_per_cpu(data) ||
cpumask_subset(affinity, cpu_online_mask)) {
raw_spin_unlock(&desc->lock);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2b8553bd8715..d00e0be8e9ea 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -336,7 +336,7 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned 
int cpu)
 
BUG_ON(irq == -1);
 #ifdef CONFIG_SMP
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(cpu));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(cpu));
 #endif
xen_evtchn_port_bind_to_cpu(info, cpu);
 
@@ -373,7 +373,7 @@ static void xen_irq_init(unsigned irq)
struct irq_info *info;
 #ifdef CONFIG_SMP
/* By default all event channels notify CPU#0. */
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(0));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(0));
 #endif
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

2015-06-02 Thread Jiang Liu
On 2015/6/3 3:19, Thomas Gleixner wrote:
> On Mon, 1 Jun 2015, Jiang Liu wrote:
> 
>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
>> index 9b62f690b0ff..dfa3a5f5b3d3 100644
>> --- a/arch/x86/kernel/apic/vector.c
>> +++ b/arch/x86/kernel/apic/vector.c
>> @@ -494,9 +494,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
>>  
>>  err = assign_irq_vector(irq, data, dest);
>>  if (err) {
>> -struct irq_data *top = irq_get_irq_data(irq);
>> -
>> -if (assign_irq_vector(irq, data, top->affinity))
>> +if (assign_irq_vector(irq, data,
>> +  irq_data_get_affinity_mask(irq_data)))
> 
> Does this patch work w/o moving the affinity mask to common data? I
> doubt so, as you remove the retrieval of 'top'.
Hi Thomas,
This piece of code should be moved into [31/36], otherwise
it will break bisecting. I will redo patch this and [31/36] to
support bisecting.
Thanks!
Gerry

> 
> Thanks,
> 
>   tglx
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

2015-06-01 Thread Jiang Liu
Use access helper irq_data_get_affinity_mask() to hide implementation
details of struct irq_desc.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/apic/io_apic.c   |2 +-
 arch/x86/kernel/apic/vector.c|5 ++---
 arch/x86/kernel/irq.c|5 +++--
 drivers/xen/events/events_base.c |4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 845dc0df2002..09921de4210f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2541,7 +2541,7 @@ void __init setup_ioapic_dest(void)
 * Honour affinities which have been set in early boot
 */
if (!irqd_can_balance(idata) || irqd_affinity_was_set(idata))
-   mask = idata->affinity;
+   mask = irq_data_get_affinity_mask(idata);
else
mask = apic->target_cpus();
 
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9b62f690b0ff..dfa3a5f5b3d3 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -494,9 +494,8 @@ static int apic_set_affinity(struct irq_data *irq_data,
 
err = assign_irq_vector(irq, data, dest);
if (err) {
-   struct irq_data *top = irq_get_irq_data(irq);
-
-   if (assign_irq_vector(irq, data, top->affinity))
+   if (assign_irq_vector(irq, data,
+ irq_data_get_affinity_mask(irq_data)))
pr_err("Failed to recover vector for irq %d\n", irq);
return err;
}
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 7e10c8b4b318..37685e37550c 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -342,7 +342,8 @@ int check_irq_vectors_for_cpu_disable(void)
continue;
 
data = irq_desc_get_irq_data(desc);
-   cpumask_copy(&affinity_new, data->affinity);
+   cpumask_copy(&affinity_new,
+irq_data_get_affinity_mask(data));
cpumask_clear_cpu(this_cpu, &affinity_new);
 
/* Do not count inactive or per-cpu irqs. */
@@ -420,7 +421,7 @@ void fixup_irqs(void)
raw_spin_lock(&desc->lock);
 
data = irq_desc_get_irq_data(desc);
-   affinity = data->affinity;
+   affinity = irq_data_get_affinity_mask(data);
if (!irq_has_action(irq) || irqd_is_per_cpu(data) ||
cpumask_subset(affinity, cpu_online_mask)) {
raw_spin_unlock(&desc->lock);
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 2b8553bd8715..d00e0be8e9ea 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -336,7 +336,7 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned 
int cpu)
 
BUG_ON(irq == -1);
 #ifdef CONFIG_SMP
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(cpu));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(cpu));
 #endif
xen_evtchn_port_bind_to_cpu(info, cpu);
 
@@ -373,7 +373,7 @@ static void xen_irq_init(unsigned irq)
struct irq_info *info;
 #ifdef CONFIG_SMP
/* By default all event channels notify CPU#0. */
-   cpumask_copy(irq_get_irq_data(irq)->affinity, cpumask_of(0));
+   cpumask_copy(irq_get_affinity_mask(irq), cpumask_of(0));
 #endif
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Patch v2 08/14] genirq: Introduce helper function irq_data_get_affinity_mask()

2015-05-20 Thread Jiang Liu
Introduce helper function irq_data_get_affinity_mask() and
irq_get_affinity_mask() to hide implementation details,
so we could move field 'affinity' from struct irq_data into
struct irq_common_data later.

Signed-off-by: Jiang Liu 
---
 arch/alpha/kernel/irq.c   |2 +-
 arch/arm/kernel/irq.c |4 ++--
 arch/arm64/kernel/irq.c   |4 ++--
 arch/blackfin/mach-common/ints-priority.c |3 ++-
 arch/ia64/kernel/iosapic.c|2 +-
 arch/ia64/kernel/irq.c|6 +++---
 arch/ia64/kernel/msi_ia64.c   |4 ++--
 arch/ia64/sn/kernel/msi_sn.c  |2 +-
 arch/metag/kernel/irq.c   |   10 ++
 arch/mips/bcm63xx/irq.c   |2 +-
 arch/mips/cavium-octeon/octeon-irq.c  |   14 --
 arch/mips/pmcs-msp71xx/msp_irq_cic.c  |3 ++-
 arch/mn10300/kernel/cevt-mn10300.c|2 +-
 arch/mn10300/kernel/irq.c |   13 +++--
 arch/parisc/kernel/irq.c  |   12 ++--
 arch/powerpc/kernel/irq.c |2 +-
 arch/powerpc/sysdev/xics/ics-opal.c   |2 +-
 arch/powerpc/sysdev/xics/ics-rtas.c   |2 +-
 arch/sh/kernel/irq.c  |7 ---
 arch/sparc/kernel/irq_64.c|   12 +++-
 arch/sparc/kernel/leon_kernel.c   |6 +++---
 arch/x86/kernel/apic/io_apic.c|2 +-
 arch/x86/kernel/apic/vector.c |5 ++---
 arch/x86/kernel/irq.c |5 +++--
 arch/xtensa/kernel/irq.c  |   10 ++
 drivers/irqchip/irq-mips-gic.c|2 +-
 drivers/parisc/iosapic.c  |2 +-
 drivers/sh/intc/chip.c|6 +++---
 drivers/xen/events/events_base.c  |4 ++--
 include/linux/irq.h   |   12 
 30 files changed, 93 insertions(+), 69 deletions(-)

diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index 7b2be251c30f..bd8e47699cad 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -60,7 +60,7 @@ int irq_select_affinity(unsigned int irq)
cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
last_cpu = cpu;
 
-   cpumask_copy(data->affinity, cpumask_of(cpu));
+   cpumask_copy(irq_data_get_affinity_mask(data), cpumask_of(cpu));
chip->irq_set_affinity(data, cpumask_of(cpu), false);
return 0;
 }
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 350f188c92d2..baf8edebe26f 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -140,7 +140,7 @@ int __init arch_probe_nr_irqs(void)
 static bool migrate_one_irq(struct irq_desc *desc)
 {
struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = d->affinity;
+   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
 
@@ -160,7 +160,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c->irq_set_affinity)
pr_debug("IRQ%u: unable to set affinity\n", d->irq);
else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(d->affinity, affinity);
+   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
 
return ret;
 }
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 240b75c0e94f..463fa2e7e34c 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -61,7 +61,7 @@ void __init init_IRQ(void)
 static bool migrate_one_irq(struct irq_desc *desc)
 {
struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = d->affinity;
+   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
 
@@ -81,7 +81,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c->irq_set_affinity)
pr_debug("IRQ%u: unable to set affinity\n", d->irq);
else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(d->affinity, affinity);
+   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
 
return ret;
 }
diff --git a/arch/blackfin/mach-common/ints-priority.c 
b/arch/blackfin/mach-common/ints-priority.c
index 7236bdfc71e6..332a434b4669 100644
--- a/arch/blackfin/mach-common/ints-priority.c
+++ b/arch/blackfin/mach-common/ints-priority.c
@@ -194,7 +194,8 @@ void bfin_internal_unmask_irq(unsigned int irq)
 #ifdef CONFIG_SMP
 static void bfin_internal_unmask_irq_chip(struct irq_data *d)
 {
-   bfin_internal_unmask_irq_affinity(d->irq, d->affinity);
+   bfin_internal_unmask_irq_affinity(d->irq,
+ irq_data_get_affinity_mask(d));

[Xen-devel] [RFC v1 06/11] genirq: Introduce helper function irq_data_get_affinity_mask()

2015-05-03 Thread Jiang Liu
Introduce helper function irq_data_get_affinity_mask() and
irq_get_affinity_mask() to hide implementation details,
so we could move field 'affinity' from struct irq_data into
struct irq_common_data later.

Signed-off-by: Jiang Liu 
---
 arch/alpha/kernel/irq.c   |2 +-
 arch/arm/kernel/irq.c |4 ++--
 arch/arm64/kernel/irq.c   |4 ++--
 arch/blackfin/mach-common/ints-priority.c |3 ++-
 arch/ia64/kernel/iosapic.c|2 +-
 arch/ia64/kernel/irq.c|6 +++---
 arch/ia64/kernel/msi_ia64.c   |4 ++--
 arch/ia64/sn/kernel/msi_sn.c  |2 +-
 arch/metag/kernel/irq.c   |   10 ++
 arch/mips/bcm63xx/irq.c   |2 +-
 arch/mips/cavium-octeon/octeon-irq.c  |   14 --
 arch/mips/pmcs-msp71xx/msp_irq_cic.c  |3 ++-
 arch/mn10300/kernel/cevt-mn10300.c|2 +-
 arch/mn10300/kernel/irq.c |   13 +++--
 arch/parisc/kernel/irq.c  |   12 ++--
 arch/powerpc/kernel/irq.c |2 +-
 arch/powerpc/sysdev/xics/ics-opal.c   |2 +-
 arch/powerpc/sysdev/xics/ics-rtas.c   |2 +-
 arch/sh/kernel/irq.c  |7 ---
 arch/sparc/kernel/irq_64.c|   12 +++-
 arch/sparc/kernel/leon_kernel.c   |6 +++---
 arch/x86/kernel/apic/io_apic.c|2 +-
 arch/x86/kernel/apic/vector.c |5 ++---
 arch/x86/kernel/irq.c |5 +++--
 arch/xtensa/kernel/irq.c  |   10 ++
 drivers/irqchip/irq-mips-gic.c|2 +-
 drivers/parisc/iosapic.c  |2 +-
 drivers/sh/intc/chip.c|6 +++---
 drivers/xen/events/events_base.c  |4 ++--
 include/linux/irq.h   |   11 +++
 30 files changed, 92 insertions(+), 69 deletions(-)

diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index 7b2be251c30f..bd8e47699cad 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -60,7 +60,7 @@ int irq_select_affinity(unsigned int irq)
cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
last_cpu = cpu;
 
-   cpumask_copy(data->affinity, cpumask_of(cpu));
+   cpumask_copy(irq_data_get_affinity_mask(data), cpumask_of(cpu));
chip->irq_set_affinity(data, cpumask_of(cpu), false);
return 0;
 }
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 350f188c92d2..baf8edebe26f 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -140,7 +140,7 @@ int __init arch_probe_nr_irqs(void)
 static bool migrate_one_irq(struct irq_desc *desc)
 {
struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = d->affinity;
+   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
 
@@ -160,7 +160,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c->irq_set_affinity)
pr_debug("IRQ%u: unable to set affinity\n", d->irq);
else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(d->affinity, affinity);
+   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
 
return ret;
 }
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 240b75c0e94f..463fa2e7e34c 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -61,7 +61,7 @@ void __init init_IRQ(void)
 static bool migrate_one_irq(struct irq_desc *desc)
 {
struct irq_data *d = irq_desc_get_irq_data(desc);
-   const struct cpumask *affinity = d->affinity;
+   const struct cpumask *affinity = irq_data_get_affinity_mask(d);
struct irq_chip *c;
bool ret = false;
 
@@ -81,7 +81,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (!c->irq_set_affinity)
pr_debug("IRQ%u: unable to set affinity\n", d->irq);
else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK && 
ret)
-   cpumask_copy(d->affinity, affinity);
+   cpumask_copy(irq_data_get_affinity_mask(d), affinity);
 
return ret;
 }
diff --git a/arch/blackfin/mach-common/ints-priority.c 
b/arch/blackfin/mach-common/ints-priority.c
index 7236bdfc71e6..332a434b4669 100644
--- a/arch/blackfin/mach-common/ints-priority.c
+++ b/arch/blackfin/mach-common/ints-priority.c
@@ -194,7 +194,8 @@ void bfin_internal_unmask_irq(unsigned int irq)
 #ifdef CONFIG_SMP
 static void bfin_internal_unmask_irq_chip(struct irq_data *d)
 {
-   bfin_internal_unmask_irq_affinity(d->irq, d->affinity);
+   bfin_internal_unmask_irq_affinity(d->irq,
+ irq_data_get_affinity_mask(d));

[Xen-devel] [Patch v4 01/23] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

2015-02-04 Thread Jiang Liu
From: Lv Zheng 

struct acpi_resource_address and struct acpi_resource_extended_address64 share 
substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.

This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
 arch/ia64/kernel/acpi-ext.c
 arch/ia64/pci/pci.c
 arch/x86/pci/acpi.c
 arch/x86/pci/mmconfig-shared.c
 drivers/xen/xen-acpi-memhotplug.c
 drivers/acpi/acpi_memhotplug.c
 drivers/acpi/pci_root.c
 drivers/acpi/resource.c
 drivers/char/hpet.c
 drivers/pnp/pnpacpi/rsparser.c
 drivers/hv/vmbus_drv.c

Build tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.

Original-by: Thomas Gleixner 
Original-by: Jiang Liu 
Signed-off-by: Lv Zheng 
Signed-off-by: Jiang Liu 
---
 arch/ia64/kernel/acpi-ext.c   |6 ++--
 arch/ia64/pci/pci.c   |   14 -
 arch/x86/pci/acpi.c   |   26 
 arch/x86/pci/mmconfig-shared.c|6 ++--
 drivers/acpi/acpi_memhotplug.c|8 ++---
 drivers/acpi/acpica/rsaddr.c  |9 +++---
 drivers/acpi/acpica/rsdumpinfo.c  |   59 +++--
 drivers/acpi/acpica/rsxface.c |   10 +++
 drivers/acpi/pci_root.c   |6 ++--
 drivers/acpi/resource.c   |   24 +++
 drivers/char/hpet.c   |4 +--
 drivers/hv/vmbus_drv.c|4 +--
 drivers/pnp/pnpacpi/rsparser.c|   16 +-
 drivers/xen/xen-acpi-memhotplug.c |8 ++---
 include/acpi/acrestyp.h   |   40 +++--
 15 files changed, 125 insertions(+), 115 deletions(-)

diff --git a/arch/ia64/kernel/acpi-ext.c b/arch/ia64/kernel/acpi-ext.c
index 8b9318d311a0..bd09bf74f187 100644
--- a/arch/ia64/kernel/acpi-ext.c
+++ b/arch/ia64/kernel/acpi-ext.c
@@ -69,10 +69,10 @@ static acpi_status find_csr_space(struct acpi_resource 
*resource, void *data)
status = acpi_resource_to_address64(resource, &addr);
if (ACPI_SUCCESS(status) &&
addr.resource_type == ACPI_MEMORY_RANGE &&
-   addr.address_length &&
+   addr.address.address_length &&
addr.producer_consumer == ACPI_CONSUMER) {
-   space->base = addr.minimum;
-   space->length = addr.address_length;
+   space->base = addr.address.minimum;
+   space->length = addr.address.address_length;
return AE_CTRL_TERMINATE;
}
return AE_OK;   /* keep looking */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 900cc93e5409..48cc65705db4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -188,12 +188,12 @@ static u64 add_io_space(struct pci_root_info *info,
 
name = (char *)(iospace + 1);
 
-   min = addr->minimum;
-   max = min + addr->address_length - 1;
+   min = addr->address.minimum;
+   max = min + addr->address.address_length - 1;
if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
sparse = 1;
 
-   space_nr = new_space(addr->translation_offset, sparse);
+   space_nr = new_space(addr->address.translation_offset, sparse);
if (space_nr == ~0)
goto free_resource;
 
@@ -247,7 +247,7 @@ static acpi_status resource_to_window(struct acpi_resource 
*resource,
if (ACPI_SUCCESS(status) &&
(addr->resource_type == ACPI_MEMORY_RANGE ||
 addr->resource_type == ACPI_IO_RANGE) &&
-   addr->address_length &&
+   addr->address.address_length &&
addr->producer_consumer == ACPI_PRODUCER)
return AE_OK;
 
@@ -284,7 +284,7 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
if (addr.resource_type == ACPI_MEMORY_RANGE) {
flags = IORESOURCE_MEM;
root = &iomem_resource;
-   offset = addr.translation_offset;
+   offset = addr.address.translation_offset;
} else if (addr.resource_type == ACPI_IO_RANGE) {
flags = IORESOURCE_IO;
root = &ioport_resource;
@@ -297,8 +297,8 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
resource = &info->res[info->res_num];
resource->name = info->name;
resource->flags = flags;
-   resource->start = addr.minimum + offset;
-   resource->end = resource->start + addr.address_length - 1;
+   resource->start = addr.address.minimum + offset;
+   resource->end = re

[Xen-devel] [Patch v2 01/23] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

2015-02-01 Thread Jiang Liu
From: Lv Zheng 

struct acpi_resource_address and struct acpi_resource_extended_address64 share 
substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.

This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
 arch/ia64/kernel/acpi-ext.c
 arch/ia64/pci/pci.c
 arch/x86/pci/acpi.c
 arch/x86/pci/mmconfig-shared.c
 drivers/xen/xen-acpi-memhotplug.c
 drivers/acpi/acpi_memhotplug.c
 drivers/acpi/pci_root.c
 drivers/acpi/resource.c
 drivers/char/hpet.c
 drivers/pnp/pnpacpi/rsparser.c
 drivers/hv/vmbus_drv.c

Build tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.

Original-by: Thomas Gleixner 
Original-by: Jiang Liu 
Signed-off-by: Lv Zheng 
Signed-off-by: Jiang Liu 
---
 arch/ia64/kernel/acpi-ext.c   |6 ++--
 arch/ia64/pci/pci.c   |   14 -
 arch/x86/pci/acpi.c   |   26 
 arch/x86/pci/mmconfig-shared.c|6 ++--
 drivers/acpi/acpi_memhotplug.c|8 ++---
 drivers/acpi/acpica/rsaddr.c  |9 +++---
 drivers/acpi/acpica/rsdumpinfo.c  |   59 +++--
 drivers/acpi/acpica/rsxface.c |   10 +++
 drivers/acpi/pci_root.c   |6 ++--
 drivers/acpi/resource.c   |   24 +++
 drivers/char/hpet.c   |4 +--
 drivers/hv/vmbus_drv.c|4 +--
 drivers/pnp/pnpacpi/rsparser.c|   16 +-
 drivers/xen/xen-acpi-memhotplug.c |8 ++---
 include/acpi/acrestyp.h   |   40 +++--
 15 files changed, 125 insertions(+), 115 deletions(-)

diff --git a/arch/ia64/kernel/acpi-ext.c b/arch/ia64/kernel/acpi-ext.c
index 8b9318d311a0..bd09bf74f187 100644
--- a/arch/ia64/kernel/acpi-ext.c
+++ b/arch/ia64/kernel/acpi-ext.c
@@ -69,10 +69,10 @@ static acpi_status find_csr_space(struct acpi_resource 
*resource, void *data)
status = acpi_resource_to_address64(resource, &addr);
if (ACPI_SUCCESS(status) &&
addr.resource_type == ACPI_MEMORY_RANGE &&
-   addr.address_length &&
+   addr.address.address_length &&
addr.producer_consumer == ACPI_CONSUMER) {
-   space->base = addr.minimum;
-   space->length = addr.address_length;
+   space->base = addr.address.minimum;
+   space->length = addr.address.address_length;
return AE_CTRL_TERMINATE;
}
return AE_OK;   /* keep looking */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 900cc93e5409..48cc65705db4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -188,12 +188,12 @@ static u64 add_io_space(struct pci_root_info *info,
 
name = (char *)(iospace + 1);
 
-   min = addr->minimum;
-   max = min + addr->address_length - 1;
+   min = addr->address.minimum;
+   max = min + addr->address.address_length - 1;
if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
sparse = 1;
 
-   space_nr = new_space(addr->translation_offset, sparse);
+   space_nr = new_space(addr->address.translation_offset, sparse);
if (space_nr == ~0)
goto free_resource;
 
@@ -247,7 +247,7 @@ static acpi_status resource_to_window(struct acpi_resource 
*resource,
if (ACPI_SUCCESS(status) &&
(addr->resource_type == ACPI_MEMORY_RANGE ||
 addr->resource_type == ACPI_IO_RANGE) &&
-   addr->address_length &&
+   addr->address.address_length &&
addr->producer_consumer == ACPI_PRODUCER)
return AE_OK;
 
@@ -284,7 +284,7 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
if (addr.resource_type == ACPI_MEMORY_RANGE) {
flags = IORESOURCE_MEM;
root = &iomem_resource;
-   offset = addr.translation_offset;
+   offset = addr.address.translation_offset;
} else if (addr.resource_type == ACPI_IO_RANGE) {
flags = IORESOURCE_IO;
root = &ioport_resource;
@@ -297,8 +297,8 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
resource = &info->res[info->res_num];
resource->name = info->name;
resource->flags = flags;
-   resource->start = addr.minimum + offset;
-   resource->end = resource->start + addr.address_length - 1;
+   resource->start = addr.address.minimum + offset;
+   resource->end = re

[Xen-devel] [Patch v2 01/22] ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

2015-01-28 Thread Jiang Liu
From: Lv Zheng 

struct acpi_resource_address and struct acpi_resource_extended_address64 share 
substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.

This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
 arch/ia64/kernel/acpi-ext.c
 arch/ia64/pci/pci.c
 arch/x86/pci/acpi.c
 arch/x86/pci/mmconfig-shared.c
 drivers/xen/xen-acpi-memhotplug.c
 drivers/acpi/acpi_memhotplug.c
 drivers/acpi/pci_root.c
 drivers/acpi/resource.c
 drivers/char/hpet.c
 drivers/pnp/pnpacpi/rsparser.c
 drivers/hv/vmbus_drv.c

Build tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.

Original-by: Thomas Gleixner 
Original-by: Jiang Liu 
Signed-off-by: Lv Zheng 
Signed-off-by: Jiang Liu 
---
 arch/ia64/kernel/acpi-ext.c   |6 ++--
 arch/ia64/pci/pci.c   |   14 -
 arch/x86/pci/acpi.c   |   26 
 arch/x86/pci/mmconfig-shared.c|6 ++--
 drivers/acpi/acpi_memhotplug.c|8 ++---
 drivers/acpi/acpica/rsaddr.c  |9 +++---
 drivers/acpi/acpica/rsdumpinfo.c  |   59 +++--
 drivers/acpi/acpica/rsxface.c |   10 +++
 drivers/acpi/pci_root.c   |6 ++--
 drivers/acpi/resource.c   |   24 +++
 drivers/char/hpet.c   |4 +--
 drivers/hv/vmbus_drv.c|4 +--
 drivers/pnp/pnpacpi/rsparser.c|   16 +-
 drivers/xen/xen-acpi-memhotplug.c |8 ++---
 include/acpi/acrestyp.h   |   40 +++--
 15 files changed, 125 insertions(+), 115 deletions(-)

diff --git a/arch/ia64/kernel/acpi-ext.c b/arch/ia64/kernel/acpi-ext.c
index 8b9318d311a0..bd09bf74f187 100644
--- a/arch/ia64/kernel/acpi-ext.c
+++ b/arch/ia64/kernel/acpi-ext.c
@@ -69,10 +69,10 @@ static acpi_status find_csr_space(struct acpi_resource 
*resource, void *data)
status = acpi_resource_to_address64(resource, &addr);
if (ACPI_SUCCESS(status) &&
addr.resource_type == ACPI_MEMORY_RANGE &&
-   addr.address_length &&
+   addr.address.address_length &&
addr.producer_consumer == ACPI_CONSUMER) {
-   space->base = addr.minimum;
-   space->length = addr.address_length;
+   space->base = addr.address.minimum;
+   space->length = addr.address.address_length;
return AE_CTRL_TERMINATE;
}
return AE_OK;   /* keep looking */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 900cc93e5409..48cc65705db4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -188,12 +188,12 @@ static u64 add_io_space(struct pci_root_info *info,
 
name = (char *)(iospace + 1);
 
-   min = addr->minimum;
-   max = min + addr->address_length - 1;
+   min = addr->address.minimum;
+   max = min + addr->address.address_length - 1;
if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
sparse = 1;
 
-   space_nr = new_space(addr->translation_offset, sparse);
+   space_nr = new_space(addr->address.translation_offset, sparse);
if (space_nr == ~0)
goto free_resource;
 
@@ -247,7 +247,7 @@ static acpi_status resource_to_window(struct acpi_resource 
*resource,
if (ACPI_SUCCESS(status) &&
(addr->resource_type == ACPI_MEMORY_RANGE ||
 addr->resource_type == ACPI_IO_RANGE) &&
-   addr->address_length &&
+   addr->address.address_length &&
addr->producer_consumer == ACPI_PRODUCER)
return AE_OK;
 
@@ -284,7 +284,7 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
if (addr.resource_type == ACPI_MEMORY_RANGE) {
flags = IORESOURCE_MEM;
root = &iomem_resource;
-   offset = addr.translation_offset;
+   offset = addr.address.translation_offset;
} else if (addr.resource_type == ACPI_IO_RANGE) {
flags = IORESOURCE_IO;
root = &ioport_resource;
@@ -297,8 +297,8 @@ static acpi_status add_window(struct acpi_resource *res, 
void *data)
resource = &info->res[info->res_num];
resource->name = info->name;
resource->flags = flags;
-   resource->start = addr.minimum + offset;
-   resource->end = resource->start + addr.address_length - 1;
+   resource->start = addr.address.minimum + offset;
+   resource->end = re

[Xen-devel] [Resend Patch v4 12/16] smp, x86: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Steven Rostedt 
Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/entry_arch.h|1 -
 arch/x86/include/asm/hw_irq.h|3 ---
 arch/x86/include/asm/irq_vectors.h   |7 +++
 arch/x86/include/asm/trace/irq_vectors.h |6 --
 arch/x86/kernel/entry_64.S   |2 --
 arch/x86/kernel/irqinit.c|4 
 arch/x86/kernel/smp.c|   24 +---
 arch/x86/xen/smp.c   |1 -
 8 files changed, 4 insertions(+), 44 deletions(-)

diff --git a/arch/x86/include/asm/entry_arch.h 
b/arch/x86/include/asm/entry_arch.h
index dc5fa661465f..9670cff64e93 100644
--- a/arch/x86/include/asm/entry_arch.h
+++ b/arch/x86/include/asm/entry_arch.h
@@ -12,7 +12,6 @@
 #ifdef CONFIG_SMP
 BUILD_INTERRUPT(reschedule_interrupt,RESCHEDULE_VECTOR)
 BUILD_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR)
-BUILD_INTERRUPT(call_function_single_interrupt,CALL_FUNCTION_SINGLE_VECTOR)
 BUILD_INTERRUPT3(irq_move_cleanup_interrupt, IRQ_MOVE_CLEANUP_VECTOR,
 smp_irq_move_cleanup_interrupt)
 BUILD_INTERRUPT3(reboot_interrupt, REBOOT_VECTOR, smp_reboot_interrupt)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 9662290e0b20..4a7f5d4cfcdb 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -75,7 +75,6 @@ extern asmlinkage void reboot_interrupt(void);
 extern asmlinkage void threshold_interrupt(void);
 
 extern asmlinkage void call_function_interrupt(void);
-extern asmlinkage void call_function_single_interrupt(void);
 
 #ifdef CONFIG_TRACING
 /* Interrupt handlers registered during init_IRQ */
@@ -88,7 +87,6 @@ extern void trace_thermal_interrupt(void);
 extern void trace_reschedule_interrupt(void);
 extern void trace_threshold_interrupt(void);
 extern void trace_call_function_interrupt(void);
-extern void trace_call_function_single_interrupt(void);
 #define trace_irq_move_cleanup_interrupt  irq_move_cleanup_interrupt
 #define trace_reboot_interrupt  reboot_interrupt
 #define trace_kvm_posted_intr_ipi kvm_posted_intr_ipi
@@ -177,7 +175,6 @@ extern asmlinkage void smp_irq_move_cleanup_interrupt(void);
 #ifdef CONFIG_SMP
 extern __visible void smp_reschedule_interrupt(struct pt_regs *);
 extern __visible void smp_call_function_interrupt(struct pt_regs *);
-extern __visible void smp_call_function_single_interrupt(struct pt_regs *);
 extern __visible void smp_invalidate_interrupt(struct pt_regs *);
 #endif
 
diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 666c89ec4bd7..bab7f0a1edde 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -92,10 +92,9 @@
 #define ERROR_APIC_VECTOR  0xfe
 #define RESCHEDULE_VECTOR  0xfd
 #define CALL_FUNCTION_VECTOR   0xfc
-#define CALL_FUNCTION_SINGLE_VECTOR0xfb
-#define THERMAL_APIC_VECTOR0xfa
-#define THRESHOLD_APIC_VECTOR  0xf9
-#define REBOOT_VECTOR  0xf8
+#define THERMAL_APIC_VECTOR0xfb
+#define THRESHOLD_APIC_VECTOR  0xfa
+#define REBOOT_VECTOR  0xf9
 
 /*
  * Generic system vector for platform specific use
diff --git a/arch/x86/include/asm/trace/irq_vectors.h 
b/arch/x86/include/asm/trace/irq_vectors.h
index 4cab890007a7..e672e203edc1 100644
--- a/arch/x86/include/asm/trace/irq_vectors.h
+++ b/arch/x86/include/asm/trace/irq_vectors.h
@@ -89,12 +89,6 @@ TRACE_EVENT_PERF_PERM(irq_work_exit, 
is_sampling_event(p_event) ? -EPERM : 0);
 DEFINE_IRQ_VECTOR_EVENT(call_function);
 
 /*
- * call_function_single - called when entering/exiting a call function
- * single interrupt vector handler
- */
-DEFINE_IRQ_VECTOR_EVENT(call_function_single);
-
-/*
  * threshold_apic - called when entering/exiting a threshold apic interrupt
  * vector handler
  */
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 9ebaf63ba182..284e5741a9ba 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1001,8 +1001,6 @@ apicinterrupt THERMAL_APIC_VECTOR \
 #endif
 
 #ifdef CONFIG_SMP
-apicinterrupt CALL_FUNCTION_SINGLE_VECTOR \
-   call_function_single_interrupt smp_call_function_single_interrupt
 apicinterrupt CALL_FUNCTION_VECTOR \
call_function_interrupt smp_call_function_interrupt
 apicinterrupt RESCHEDULE_VECTOR \
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index 70e181ea1eac..d72a8c4da145 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -111,10 +111,6 @@ s

[Xen-devel] [Resend Patch v4 11/16] smp, x86, xen: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
Acked-by: Konrad Rzeszutek Wilk 
Cc: x...@kernel.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/xen/events.h |1 -
 arch/x86/xen/smp.c|   38 ++---
 2 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h 
b/arch/x86/include/asm/xen/events.h
index 608a79d5a466..a9e54dc05c50 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -4,7 +4,6 @@
 enum ipi_vector {
XEN_RESCHEDULE_VECTOR,
XEN_CALL_FUNCTION_VECTOR,
-   XEN_CALL_FUNCTION_SINGLE_VECTOR,
XEN_SPIN_UNLOCK_VECTOR,
XEN_IRQ_WORK_VECTOR,
XEN_NMI_VECTOR,
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..d54c122a0486 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -47,12 +47,10 @@ struct xen_common_irq {
 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_resched_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfunc_irq) = { .irq = -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_callfuncsingle_irq) = { .irq 
= -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_irq_work) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_debug_irq) = { .irq = -1 };
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
-static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
@@ -136,13 +134,6 @@ static void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_debug_irq, cpu).name);
per_cpu(xen_debug_irq, cpu).name = NULL;
}
-   if (per_cpu(xen_callfuncsingle_irq, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu).irq,
-  NULL);
-   per_cpu(xen_callfuncsingle_irq, cpu).irq = -1;
-   kfree(per_cpu(xen_callfuncsingle_irq, cpu).name);
-   per_cpu(xen_callfuncsingle_irq, cpu).name = NULL;
-   }
if (xen_hvm_domain())
return;
 
@@ -191,18 +182,6 @@ static int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_debug_irq, cpu).irq = rc;
per_cpu(xen_debug_irq, cpu).name = debug_name;
 
-   callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
-   rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR,
-   cpu,
-   xen_call_function_single_interrupt,
-   IRQF_PERCPU|IRQF_NOBALANCING,
-   callfunc_name,
-   NULL);
-   if (rc < 0)
-   goto fail;
-   per_cpu(xen_callfuncsingle_irq, cpu).irq = rc;
-   per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
-
/*
 * The IRQ worker on PVHVM goes through the native path and uses the
 * IPI mechanism.
@@ -599,8 +578,7 @@ static void xen_smp_send_call_function_ipi(const struct 
cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-   __xen_send_IPI_mask(cpumask_of(cpu),
- XEN_CALL_FUNCTION_SINGLE_VECTOR);
+   __xen_send_IPI_mask(cpumask_of(cpu), XEN_CALL_FUNCTION_VECTOR);
 }
 
 static inline int xen_map_vector(int vector)
@@ -612,10 +590,8 @@ static inline int xen_map_vector(int vector)
xen_vector = XEN_RESCHEDULE_VECTOR;
break;
case CALL_FUNCTION_VECTOR:
-   xen_vector = XEN_CALL_FUNCTION_VECTOR;
-   break;
case CALL_FUNCTION_SINGLE_VECTOR:
-   xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+   xen_vector = XEN_CALL_FUNCTION_VECTOR;
break;
case IRQ_WORK_VECTOR:
xen_vector = XEN_IRQ_WORK_VECTOR;
@@ -693,16 +669,6 @@ static irqreturn_t xen_call_function_interrupt(int irq, 
void *dev_id)
return IRQ_HANDLED;
 }
 
-static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
-{
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   inc_irq_stat(irq_call_count);
-   irq_exit();
-
-   return IRQ_HANDLED;
-}
-
 static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
 {
irq_enter();
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


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

2015-01-19 Thread 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 
Tested-by: Sander Eikelenboom 
---
 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


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


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

2015-01-19 Thread 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 
Tested-by: Sander Eikelenboom 
---
 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

Re: [Xen-devel] [Bugfix 0/3] Fix regressions in Xen IRQ management

2015-01-19 Thread Jiang Liu
gt; 
> So to summarize:
> The reported problems are fixed, everything looks good.
> Apart from a splat which occurs infrequently and from which i don't know
> if it is due to this patch set anyway.
> 
> So i'm very much inclined to say: 
> Tested-by: Sander Eikelenboom 
Thanks for your great efforts to tests those patches, Sander.
I will send out formal patch set for 3.19 tomorrow.
Thanks!
Gerry

> 
> 
> Thanks Gerry !
> 
> --
> Sander
> 
>> Jiang Liu (3):
>>   xen/irq, ACPI: Fix regression in xen PCI passthrough caused by
>> cffe0a2b5a34
>>   xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi
>>   x86/PCI: Refine the way to release PCI IRQ resources
> 
>>  arch/x86/include/asm/acpi.h|1 +
>>  arch/x86/include/asm/pci_x86.h |2 --
>>  arch/x86/pci/common.c  |   30 --
>>  arch/x86/pci/intel_mid_pci.c   |4 ++--
>>  arch/x86/pci/irq.c |   15 +--
>>  arch/x86/pci/xen.c |2 ++
>>  drivers/acpi/pci_irq.c |   10 +-
>>  7 files changed, 35 insertions(+), 29 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Bugfix 2/3] xen/irq: Override ACPI IRQ management callback __acpi_unregister_gsi

2015-01-18 Thread 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 
---
 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


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Bugfix v4 1/2] xen/pci: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-18 Thread Jiang Liu

On 2015/1/17 2:13, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 15, 2015 at 09:04:35PM +0800, Jiang Liu wrote:

>>
>> Note: we need to test this patch on those special AMD systems which
>> override normal SCI GSI (9) with strange GSI (20).
> 
> [0.00] DMI: Supermicro X8DTN/X8DTN, BIOS 2.1c   10/28/2011
> ..
>  0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
> [0.00] ACPI: IRQ0 used by override.
> ..
> 6.358737] xen: registering gsi 20 triggering 0 polarity 1
> [6.358756] xen: --> pirq=20 -> irq=20 (gsi=20)
> ...
> -bash-4.1# cat /proc/interrupts |grep acpi
>  20:  0  0  0  xen-pirq-ioapic-level  acpi
Hi Konrad,
May I assume an Tested-by from you here?
Thanks!
Gerry

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Bugfix v4 1/2] xen/pci: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-18 Thread Jiang Liu

On 2015/1/17 2:13, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 15, 2015 at 09:04:35PM +0800, Jiang Liu wrote:

>>
>> Note: we need to test this patch on those special AMD systems which
>> override normal SCI GSI (9) with strange GSI (20).
> 
> [0.00] DMI: Supermicro X8DTN/X8DTN, BIOS 2.1c   10/28/2011
> ..
>  0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
> [0.00] ACPI: IRQ0 used by override.
> ..
> 6.358737] xen: registering gsi 20 triggering 0 polarity 1
> [6.358756] xen: --> pirq=20 -> irq=20 (gsi=20)
> ...
> -bash-4.1# cat /proc/interrupts |grep acpi
>  20:  0  0  0  xen-pirq-ioapic-level  acpi
> 
Thanks Konrad, it works as expected. Previously IRQ9 was assigned
to ACPI SCI GSI 20, now it assigns IRQ20. But that's OK, ACPI has
no special requirement about the assigned IRQ number, we could
assign any valid IRQ number for ACPI SCI GSI.
Thanks!
Gerry


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Bugfix v4 2/2] xen/pci: Simplify x86/pci/xen.c by killing gsi_override related code

2015-01-15 Thread Jiang Liu
There's no use of gsi_override related logic anymore, so kill code
related to gsi_override.

Signed-off-by: Jiang Liu 
---
 arch/x86/pci/xen.c |   21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c3c644..a73c3bd71243 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -59,8 +59,7 @@ static int xen_pcifront_enable_irq(struct pci_dev *dev)
 }
 
 #ifdef CONFIG_ACPI
-static int xen_register_pirq(u32 gsi, int gsi_override, int triggering,
-bool set_pirq)
+static int xen_register_pirq(u32 gsi, int triggering, bool set_pirq)
 {
int rc, pirq = -1, irq = -1;
struct physdev_map_pirq map_irq;
@@ -93,9 +92,6 @@ static int xen_register_pirq(u32 gsi, int gsi_override, int 
triggering,
name = "ioapic-level";
}
 
-   if (gsi_override >= 0)
-   gsi = gsi_override;
-
irq = xen_bind_pirq_gsi_to_irq(gsi, map_irq.pirq, shareable, name);
if (irq < 0)
goto out;
@@ -111,12 +107,13 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, 
u32 gsi,
if (!xen_hvm_domain())
return -1;
 
-   return xen_register_pirq(gsi, -1 /* no GSI override */, trigger,
+   return xen_register_pirq(gsi, trigger,
 false /* no mapping of GSI to PIRQ */);
 }
 
 #ifdef CONFIG_XEN_DOM0
-static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int 
polarity)
+static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
+int triggering, int polarity)
 {
int rc, irq;
struct physdev_setup_gsi setup_gsi;
@@ -127,7 +124,7 @@ static int xen_register_gsi(u32 gsi, int gsi_override, int 
triggering, int polar
printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
gsi, triggering, polarity);
 
-   irq = xen_register_pirq(gsi, gsi_override, triggering, true);
+   irq = xen_register_pirq(gsi, triggering, true);
 
setup_gsi.gsi = gsi;
setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
@@ -143,12 +140,6 @@ static int xen_register_gsi(u32 gsi, int gsi_override, int 
triggering, int polar
 
return irq;
 }
-
-static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
-int trigger, int polarity)
-{
-   return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, 
polarity);
-}
 #endif
 #endif
 
@@ -489,7 +480,7 @@ int __init pci_xen_initial_domain(void)
if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
continue;
 
-   xen_register_pirq(irq, -1 /* no GSI override */,
+   xen_register_pirq(irq,
trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE,
true /* Map GSI to PIRQ */);
}
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Bugfix v4 1/2] xen/pci: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-15 Thread Jiang Liu
Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
setup_IO_APIC(), so no irqdomains created for IOAPICs and
mp_map_pin_to_irq() fails at the very beginning.

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.

Note: we need to test this patch on those special AMD systems which
override normal SCI GSI (9) with strange GSI (20).

Signed-off-by: Jiang Liu 
---
 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 4433a4be8171..395c4c615293 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

Re: [Xen-devel] 3.19-rc4: Xen pci-passthrough regression, bisected to commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: Keep balance of IOAPIC pin reference count"

2015-01-15 Thread Jiang Liu
Hi Sander,
It really cost me some time to understand HVM, PVH, Dom0, PV and
read Xen interrupt related code:( Now I have basic understanding of
related staffs. The patch for previous issue is actually wrong and
I'm working on another fixes for it. I will handle this issue once
getting done with the previous issue.
Sorry for the delay.
Regards!
Gerry

On 2015/1/15 0:17, Sander Eikelenboom wrote:
> 
> Wednesday, January 14, 2015, 3:58:33 PM, you wrote:
> 
>> On 14/01/15 14:15, Sander Eikelenboom wrote:
>>> Hi Gerry / David / Konrad,
>>>
>>> Some more testing uncovered another issue under Xen, this time with 
>>> PCI-passthrough.
> 
>> What device?  In particular what interrupts is it using?
> 
> Hi David,
> 
> Here is a more complete set of debug logs, for both with and without the 
> revert.
> - dmesg
> - xl-dmesg with output of debug keys 'i, M, z'
> - lspci part of the two devices from the guest
> - /proc/interrupts
> 
> The wifi NIC (dom0: 02:00.0 guest: 00:05.0) uses legacy interrupts and gives 
> troubles:
> It's using:
> Interrupt: pin A routed to IRQ 36
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
> 36:  14413  xen-pirq-ioapic-level  ath9k
> 
> The other NIC (dom0: 00:19.0 guest: 00:06.0) uses MSI interrupts and that 
> works fine:
> Interrupt: pin A routed to IRQ 57
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 57:182  xen-pirq-msi   eth0
> --
> Sander  
> 
>>> I have bisected it to the following commit: 
>>> cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: Keep balance of IOAPIC 
>>> pin reference count"
>>>
>>> It causes these symptoms:
>>>
>>> - On Intel
>>>   - Running on Xen with pci devices seized on host boot with 
>>> xen-pciback.hide= parameter
>>>   - Running a HVM guest with PCI passthrough of two devices (NIC + wireless 
>>> NIC)
>>>   - While the driver loads fine, the device isn't working properly, looking 
>>> in /proc/interrupts in the guest
>>> shows that it doesn't receive any interrupts.
>>>   - Reverting this particular commit (in the dom0 kernel only) makes the 
>>> device receive interrupts and work properly again.
>>>
>>> - On AMD (more subtle symptom) 
>>>   - Running on Xen with pci devices seized on host boot with 
>>> xen-pciback.hide= parameter
>>>   - Running a HVM guest with PCI passthrough of one devices (videograbber)
>>>   - While the driver loads fine and the device looks like it's working, the 
>>> videostream isn't stable and it skips or repeats frames.
>>>   - Reverting this particular commit (in the dom0 kernel only) makes the 
>>> device work properly again with a stable videostream.
>>>
>>> --
>>> Sander
>>>
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-13 Thread Jiang Liu
On 2015/1/13 18:09, David Vrabel wrote:
> On 13/01/15 02:23, Jiang Liu wrote:
>> On 2015/1/12 23:01, David Vrabel wrote:
>>> On 12/01/15 13:39, Jiang Liu wrote:
>>>> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
>>>> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
>>>> setup_IO_APIC(), so no irqdomains created for IOAPICs and
>>>> mp_map_pin_to_irq() fails at the very beginning.
>>>>
>>>> Enhance xen_smp_prepare_cpus() to call setup_IO_APIC() to initialize
>>>> irqdomain for IOAPICs.
>>>
>>> Having Xen call setup_IO_APIC() to initialize the irq domains then having to
>>> add special cases to it is just wrong.
>>>
>>> The bits of init deferred by mp_register_apic() are also deferred to
>>> two different places which looks odd.
>>>
>>> What about something like the following (untested) patch?
>> Hi David,
>>  Really appreciate your suggestions about Xen IOAPIC:)
>> Your patch solves the issue, but it will break a coming patch
>> set to enable hierarchy irqdomain on x86.
> 
> For 3.19 I would recommend this patch.  Since it's been tested and it's
> pretty small.  Can you spin a version of this with a proper changelog.
> please?
Hi David,
Good suggestion, I will send out the patch tomorrow.
Regards!
Gerry

> 
>>  To enable hierarchy irqdomain on x86, need to build
>> irqdomains in following order:
>> 1) create irqdomain for CPU vector domain
>> 2) create irqdomains for interrupt remapping unit if interrupt
>>remapping is enabled.
>> 3) create irqdomains for IOAPIC/MSI/HPET etc.
>>
>> Function arch_early_ioapic_init() is called before initializing
>> interrupt remapping subsystem. So creating IOAPIC irqdomains in
>> arch_early_ioapic_init() will break hierarchy irqdomain with
>> interrupt remapping enabled. I will post the x86 hierarchy
>> irqdomain patch soon.
>>
>> So could you please help to advice on:
> 
> I don't know enough about this area to comment on these authoritatively
> and I don't have time to look into this in more detail right now, but to
> the best of my understanding.
> 
>> 1) Is IOAPIC irqdomain needed for PV?
> 
> PV dom0 only requires a mechanism to obtain properties of the IOAPIC
> interrupt lines.  The actual physical interrupts are delivered to the
> hypervisor.  It doesn't require any of the irq setup.
> 
>> 2) Is IOAPIC irqdomain needed for HVM?
> 
> Yes.
> 
>> 3) Is IOAPIC irqdomain needed for Dom0?
> 
> 
> See (1) above.
> 
>> 4) What's the proper hook point to create IOAPIC irqdomain for Xen
>>UP systems?
> 
> Don't know.
> 
> David
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-12 Thread Jiang Liu
On 2015/1/12 23:01, David Vrabel wrote:
> On 12/01/15 13:39, Jiang Liu wrote:
>> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
>> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
>> setup_IO_APIC(), so no irqdomains created for IOAPICs and
>> mp_map_pin_to_irq() fails at the very beginning.
>>
>> Enhance xen_smp_prepare_cpus() to call setup_IO_APIC() to initialize
>> irqdomain for IOAPICs.
> 
> Having Xen call setup_IO_APIC() to initialize the irq domains then having to
> add special cases to it is just wrong.
> 
> The bits of init deferred by mp_register_apic() are also deferred to
> two different places which looks odd.
> 
> What about something like the following (untested) patch?
Hi David,
Really appreciate your suggestions about Xen IOAPIC:)
Your patch solves the issue, but it will break a coming patch
set to enable hierarchy irqdomain on x86.
To enable hierarchy irqdomain on x86, need to build
irqdomains in following order:
1) create irqdomain for CPU vector domain
2) create irqdomains for interrupt remapping unit if interrupt
   remapping is enabled.
3) create irqdomains for IOAPIC/MSI/HPET etc.

Function arch_early_ioapic_init() is called before initializing
interrupt remapping subsystem. So creating IOAPIC irqdomains in
arch_early_ioapic_init() will break hierarchy irqdomain with
interrupt remapping enabled. I will post the x86 hierarchy
irqdomain patch soon.

So could you please help to advice on:
1) Is IOAPIC irqdomain needed for PV?
2) Is IOAPIC irqdomain needed for HVM?
3) Is IOAPIC irqdomain needed for Dom0?
4) What's the proper hook point to create IOAPIC irqdomain for Xen
   UP systems?
I really need to get more understanding of Xen interrupt subsystem:)
Thanks!
Gerry

> 
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 3f5f604..e180680 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -253,8 +253,10 @@ int __init arch_early_ioapic_init(void)
>   if (!nr_legacy_irqs())
>   io_apic_irqs = ~0UL;
>  
> - for_each_ioapic(i)
> + for_each_ioapic(i) {
> + BUG_ON(mp_irqdomain_create(ioapic));
>   alloc_ioapic_saved_registers(i);
> + }
>  
>   /*
>* For legacy IRQ's, start with assigning irq0 to irq15 to
> @@ -2379,8 +2381,6 @@ void __init setup_IO_APIC(void)
>   io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
>  
>   apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
> - for_each_ioapic(ioapic)
> - BUG_ON(mp_irqdomain_create(ioapic));
>  
>   /*
>   * Set up IO-APIC IRQ routing.
> @@ -2929,7 +2929,8 @@ int mp_register_ioapic(int id, u32 address, u32 
> gsi_base,
>   /*
>* If mp_register_ioapic() is called during early boot stage when
>* walking ACPI/SFI/DT tables, it's too early to create irqdomain,
> -  * we are still using bootmem allocator. So delay it to setup_IO_APIC().
> +  * we are still using bootmem allocator. So delay it to
> +  * arch_early_ioapic_init().
>*/
>   if (hotplug) {
>   if (mp_irqdomain_create(idx)) {
> 
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -2369,6 +2381,15 @@ static void ioapic_destroy_irqdomain(int idx)
>>  ioapics[idx].pin_info = NULL;
>>  }
>>  
>> +static void setup_IO_APIC_IDs(void)
>> +{
>> +if (xen_domain())
>> +return;
> 
> This would have to xen_pv_domain().
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [PATCH v2] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-12 Thread Jiang Liu
Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
setup_IO_APIC(), so no irqdomains created for IOAPICs and
mp_map_pin_to_irq() fails at the very beginning.

Enhance xen_smp_prepare_cpus() to call setup_IO_APIC() to initialize
irqdomain for IOAPICs.

Signed-off-by: Jiang Liu 
---
Hi Sander,
Could you please help to test this patch against 3.19-rc3?
I have reworked it based Konrad's suggestions.
Thanks!
Gerry
---
 arch/x86/kernel/apic/io_apic.c |   31 +++
 arch/x86/xen/smp.c |1 +
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 3f5f60406ab1..81d4faeb8040 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -2165,6 +2167,9 @@ static inline void __init check_timer(void)
unsigned long flags;
int no_pin1 = 0;
 
+   if (!nr_legacy_irqs())
+   return;
+
local_irq_save(flags);
 
/*
@@ -2185,6 +2190,13 @@ static inline void __init check_timer(void)
apic_write(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT);
legacy_pic->init(1);
 
+   /*
+* legacy_pic will be changed to null_legacy_pic if init() fails to
+* to detect legacy PIC hardware. Recheck again.
+*/
+   if (!nr_legacy_irqs())
+   goto out;
+
pin1  = find_isa_irq_pin(0, mp_INT);
apic1 = find_isa_irq_apic(0, mp_INT);
pin2  = ioapic_i8259.pin;
@@ -2369,6 +2381,15 @@ static void ioapic_destroy_irqdomain(int idx)
ioapics[idx].pin_info = NULL;
 }
 
+static void setup_IO_APIC_IDs(void)
+{
+   if (xen_domain())
+   return;
+
+   x86_init.mpparse.setup_ioapic_ids();
+   sync_Arb_IDs();
+}
+
 void __init setup_IO_APIC(void)
 {
int ioapic;
@@ -2382,16 +2403,10 @@ void __init setup_IO_APIC(void)
for_each_ioapic(ioapic)
BUG_ON(mp_irqdomain_create(ioapic));
 
-   /*
- * Set up IO-APIC IRQ routing.
- */
-   x86_init.mpparse.setup_ioapic_ids();
-
-   sync_Arb_IDs();
+   setup_IO_APIC_IDs();
setup_IO_APIC_irqs();
init_IO_APIC_traps();
-   if (nr_legacy_irqs())
-   check_timer();
+   check_timer();
 
ioapic_initialized = 1;
 }
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..9f404df64422 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -327,6 +327,7 @@ static void __init xen_smp_prepare_cpus(unsigned int 
max_cpus)
xen_raw_printk(m);
panic(m);
}
+   setup_IO_APIC();
xen_init_lock_cpu(0);
 
smp_store_boot_cpu_info();
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-07 Thread Jiang Liu
On 2015/1/7 23:44, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 07, 2015 at 11:37:52PM +0800, Jiang Liu wrote:
>> On 2015/1/7 22:50, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Jan 07, 2015 at 02:13:49PM +0800, Jiang Liu wrote:
>>>> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
>>>> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
>>>> setup_IO_APIC(), so no irqdomains created for IOAPICs and
>>>> mp_map_pin_to_irq() fails at the very beginning.
>>>> --- a/arch/x86/kernel/apic/io_apic.c
>>>> +++ b/arch/x86/kernel/apic/io_apic.c
>>>> @@ -2369,31 +2369,29 @@ static void ioapic_destroy_irqdomain(int idx)
>>>>ioapics[idx].pin_info = NULL;
>>>>  }
>>>>  
>>>> -void __init setup_IO_APIC(void)
>>>> +void __init setup_IO_APIC(bool xen_smp)
>>>>  {
>>>>int ioapic;
>>>>  
>>>> -  /*
>>>> -   * calling enable_IO_APIC() is moved to setup_local_APIC for BP
>>>> -   */
>>>> -  io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
>>>> +  if (!xen_smp) {
>>>> +  apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
>>>> +  io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
>>>> +
>>>> +  /* Set up IO-APIC IRQ routing. */
>>>> +  x86_init.mpparse.setup_ioapic_ids();
>>>> +  sync_Arb_IDs();
>>>> +  }
Hi Konrad,
Enabling above code for Xen dom0 will cause following warning
because it writes a special value to ICR register.
[3.394981] [ cut here ]
[3.394985] WARNING: CPU: 0 PID: 1 at arch/x86/xen/enlighten.c:968
xen_apic_write+0x15/0x20()
[3.394988] Modules linked in:
[3.394991] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc3+ #5
[3.394993] Hardware name: Dell Inc. OptiPlex 9020/0DNKMN, BIOS A03
09/17/2013
[3.394996]  03c8 88003056bdd8 817611bb
03c8
[3.395000]   88003056be18 8106f4ea
0008
[3.395004]  81fc1120 880030561348 a108
a101
[3.395008] Call Trace:
[3.395012]  [] dump_stack+0x4f/0x6c
[3.395015]  [] warn_slowpath_common+0xaa/0xd0
[3.395018]  [] warn_slowpath_null+0x15/0x20
[3.395021]  [] xen_apic_write+0x15/0x20
[3.395026]  [] sync_Arb_IDs+0x84/0x86
[3.395029]  [] setup_IO_APIC+0x7f/0x8e3
[3.395033]  [] ? trace_hardirqs_on+0xd/0x10
[3.395036]  [] ? _raw_spin_unlock_irqrestore+0x8a/0xa0
[3.395040]  [] xen_smp_prepare_cpus+0x5d/0x184
[3.395044]  [] kernel_init_freeable+0x149/0x293
[3.395047]  [] ? kernel_init+0x9/0xf0
[3.395049]  [] ? rest_init+0xd0/0xd0
[3.395052]  [] kernel_init+0x9/0xf0
[3.395054]  [] ret_from_fork+0x7c/0xb0
[3.395057]  [] ? rest_init+0xd0/0xd0
[3.395066] ---[ end trace 7c4371c8ba33d5d0 ]---


>>>>ioapic_initialized = 1;
>>>> +
>>>> +  if (!xen_smp) {
>>>> +  init_IO_APIC_traps();
>>>> +  if (nr_legacy_irqs())
>>>> +  check_timer();
>>>> +  }
>>>>  }
And enabling above code causes Xen dom0 reboots.
Haven't test HVM and PV kernel yet.
So seems we still need special treatment for xen here.
Regards!
Gerry

>>>>  
>>>>  /*
>>>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>>>> index 4c071aeb8417..7eb0283901fa 100644
>>>> --- a/arch/x86/xen/smp.c
>>>> +++ b/arch/x86/xen/smp.c
>>>> @@ -326,7 +326,10 @@ static void __init xen_smp_prepare_cpus(unsigned int 
>>>> max_cpus)
>>>>  
>>>>xen_raw_printk(m);
>>>>panic(m);
>>>> +  } else {
>>>> +  setup_IO_APIC(true);
>>>>}
>>>> +
>>>>xen_init_lock_cpu(0);
>>>>  
>>>>smp_store_boot_cpu_info();
>>>> -- 
>>>> 1.7.10.4
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-07 Thread Jiang Liu
On 2015/1/7 22:50, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 07, 2015 at 02:13:49PM +0800, Jiang Liu wrote:
>> Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
>> breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
>> setup_IO_APIC(), so no irqdomains created for IOAPICs and
>> mp_map_pin_to_irq() fails at the very beginning.
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -2369,31 +2369,29 @@ static void ioapic_destroy_irqdomain(int idx)
>>  ioapics[idx].pin_info = NULL;
>>  }
>>  
>> -void __init setup_IO_APIC(void)
>> +void __init setup_IO_APIC(bool xen_smp)
>>  {
>>  int ioapic;
>>  
>> -/*
>> - * calling enable_IO_APIC() is moved to setup_local_APIC for BP
>> - */
>> -io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
>> +if (!xen_smp) {
>> +apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
>> +io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
>> +
>> +/* Set up IO-APIC IRQ routing. */
>> +x86_init.mpparse.setup_ioapic_ids();
>> +sync_Arb_IDs();
>> +}
> 
> 
> Is there a specific reason that this cannot run in all cases?
> 
> What I am asking is why are we doing a special case here? The description
> at the top implied that we were just missing an call to
> setup_IO_APIC.. 
Hi Konrad,
I'm not very familiar with Xen IRQ yet, so I just enabled the
code to create irqdomains for IOAPICs and keep other part as is. I will
try to check whether we could enable other part all together:)
Regards!
Gerry

> 
>>  
>> -apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
>>  for_each_ioapic(ioapic)
>>  BUG_ON(mp_irqdomain_create(ioapic));
>> -
>> -/*
>> - * Set up IO-APIC IRQ routing.
>> - */
>> -x86_init.mpparse.setup_ioapic_ids();
>> -
>> -sync_Arb_IDs();
>>  setup_IO_APIC_irqs();
>> -init_IO_APIC_traps();
>> -if (nr_legacy_irqs())
>> -check_timer();
>> -
>>  ioapic_initialized = 1;
>> +
>> +if (!xen_smp) {
>> +init_IO_APIC_traps();
>> +if (nr_legacy_irqs())
>> +check_timer();
>> +}
>>  }
>>  
>>  /*
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 4c071aeb8417..7eb0283901fa 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -326,7 +326,10 @@ static void __init xen_smp_prepare_cpus(unsigned int 
>> max_cpus)
>>  
>>  xen_raw_printk(m);
>>  panic(m);
>> +} else {
>> +setup_IO_APIC(true);
>>  }
>> +
>>  xen_init_lock_cpu(0);
>>  
>>  smp_store_boot_cpu_info();
>> -- 
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

2015-01-06 Thread Jiang Liu
Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
setup_IO_APIC(), so no irqdomains created for IOAPICs and
mp_map_pin_to_irq() fails at the very beginning.

Enhance xen_smp_prepare_cpus() to call setup_IO_APIC() to initialize
irqdomain for IOAPICs.

Signed-off-by: Jiang Liu 
Reported-and-tested-by: Sander Eikelenboom 
Cc: Konrad Rzeszutek Wilk 
---
Hi all,
This patch should be backported to v3.17, but there are
conflicts. So I will send backported patch to 3.17/3.18 stable tree
once this patch has been merged into mainstream kernel.
Thanks!
Gerry
---
 arch/x86/include/asm/io_apic.h   |2 +-
 arch/x86/include/asm/smpboot_hooks.h |5 ++---
 arch/x86/kernel/apic/apic.c  |5 ++---
 arch/x86/kernel/apic/io_apic.c   |   32 +++-
 arch/x86/xen/smp.c   |3 +++
 5 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index bf006cce9418..72a1298658bb 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -237,7 +237,7 @@ static inline void io_apic_modify(unsigned int apic, 
unsigned int reg, unsigned
 
 extern void io_apic_eoi(unsigned int apic, unsigned int vector);
 
-extern void setup_IO_APIC(void);
+extern void setup_IO_APIC(bool xen_smp);
 extern void enable_IO_APIC(void);
 extern void disable_IO_APIC(void);
 extern void setup_ioapic_dest(void);
diff --git a/arch/x86/include/asm/smpboot_hooks.h 
b/arch/x86/include/asm/smpboot_hooks.h
index 0da7409f0bec..e47df710a588 100644
--- a/arch/x86/include/asm/smpboot_hooks.h
+++ b/arch/x86/include/asm/smpboot_hooks.h
@@ -53,10 +53,9 @@ static inline void __init smpboot_setup_io_apic(void)
 * go and set it up:
 */
if (!skip_ioapic_setup && nr_ioapics)
-   setup_IO_APIC();
-   else {
+   setup_IO_APIC(false);
+   else
nr_ioapics = 0;
-   }
 #endif
 }
 
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 29b5b18afa27..71b8a6cb7f0e 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1913,10 +1913,9 @@ int __init APIC_init_uniprocessor(void)
 
 #ifdef CONFIG_X86_IO_APIC
if (smp_found_config && !skip_ioapic_setup && nr_ioapics)
-   setup_IO_APIC();
-   else {
+   setup_IO_APIC(false);
+   else
nr_ioapics = 0;
-   }
 #endif
 
x86_init.timers.setup_percpu_clockev();
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 3f5f60406ab1..13cddc75e4c0 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2369,31 +2369,29 @@ static void ioapic_destroy_irqdomain(int idx)
ioapics[idx].pin_info = NULL;
 }
 
-void __init setup_IO_APIC(void)
+void __init setup_IO_APIC(bool xen_smp)
 {
int ioapic;
 
-   /*
-* calling enable_IO_APIC() is moved to setup_local_APIC for BP
-*/
-   io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+   if (!xen_smp) {
+   apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
+   io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+
+   /* Set up IO-APIC IRQ routing. */
+   x86_init.mpparse.setup_ioapic_ids();
+   sync_Arb_IDs();
+   }
 
-   apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
for_each_ioapic(ioapic)
BUG_ON(mp_irqdomain_create(ioapic));
-
-   /*
- * Set up IO-APIC IRQ routing.
- */
-   x86_init.mpparse.setup_ioapic_ids();
-
-   sync_Arb_IDs();
setup_IO_APIC_irqs();
-   init_IO_APIC_traps();
-   if (nr_legacy_irqs())
-   check_timer();
-
ioapic_initialized = 1;
+
+   if (!xen_smp) {
+   init_IO_APIC_traps();
+   if (nr_legacy_irqs())
+   check_timer();
+   }
 }
 
 /*
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..7eb0283901fa 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -326,7 +326,10 @@ static void __init xen_smp_prepare_cpus(unsigned int 
max_cpus)
 
xen_raw_printk(m);
panic(m);
+   } else {
+   setup_IO_APIC(true);
}
+
xen_init_lock_cpu(0);
 
smp_store_boot_cpu_info();
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777

2014-12-19 Thread Jiang Liu
Hi Sander,
Could you please help to test attached patch? It works
on native but I have no Xen environment at hand.
Thanks!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f61
> Author: Jiang Liu 
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
> x86, irq: Clean up irqdomain transition code
> 
> Now we have completely switched to irqdomain, so clean up transition code
> in IOAPIC drivers.
> 
> Signed-off-by: Jiang Liu 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tony Luck 
> Cc: Joerg Roedel 
> Cc: Paul Gortmaker 
> Cc: Greg Kroah-Hartman 
> Cc: Benjamin Herrenschmidt 
> Cc: Grant Likely 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: Randy Dunlap 
> Cc: Yinghai Lu 
> Link: 
> http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working 
> again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 
>From a6928b3c93a5119c79b8a7aec953579c87d2a4cc Mon Sep 17 00:00:00 2001
From: Jiang Liu 
Date: Fri, 19 Dec 2014 22:33:56 +0800
Subject: [PATCH] x86/apic: Fix xen failure caused by commit b81975eade8c

Commit b81975eade8c "x86, irq: Clean up irqdomain transition code"
breaks Xen because xen_smp_prepare_cpus() doesn't call setup_IO_APIC()
so mp_map_pin_to_irq() fails at the very beginning.

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/hw_irq.h|2 +-
 arch/x86/include/asm/smpboot_hooks.h |6 +++---
 arch/x86/kernel/apic/apic.c  |6 +++---
 arch/x86/kernel/apic/io_apic.c   |   32 +++-
 arch/x86/xen/smp.c   |3 +++
 5 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 4615906d83df..0c6530dfd817 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -98,7 +98,7 @@ extern void trace_call_function_single_interrupt(void);
 #define IO_APIC_IRQ(x) (((x) >= NR_IRQS_LEGACY) || ((1<<(x)) & io_apic_irqs))
 extern unsigned long io_apic_irqs;
 
-extern void setup_IO_APIC(void);
+extern void setup_IO_APIC(bool xen_smp);
 extern void disable_IO_APIC(void);
 
 struct io_apic_irq_attr {
diff --git a/arch/x86/include/asm/smpboot_hooks.h b/arch/x86/include/asm/smpboot_hooks.h
index 0da7409f0bec..76e5731b03cb 100644
--- a/arch/x86/include/asm/smpboot_hooks.h
+++ b/arch/x86/include/asm/smpboot_hooks.h
@@ -52,9 +52,9 @@ static inline void __init smpboot_setup_io_apic(void)
 	 * Here we can be sure that there is an IO-APIC in the system. Let's
 	 * go and set it up:
 	 */
-	if (!skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (!skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ba6cc041edb1..33ba1f97abea 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1912,9 +1912,9 @@ int __init APIC_init_uniprocessor(void)
 	bsp_end_local_APIC_setup();
 
 #ifdef CONFIG_X86_IO_APIC
-	if (smp_found_config && !skip_ioapic_setup && nr_ioapics)
-		setup_IO_APIC();
-	else {
+	if (smp_found_config && !skip_ioapic_setup && nr_ioapics) {
+		setup_IO_APIC(false);
+	} else {
 		nr_ioapics = 0;
 	}
 #endif
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a6745e756729..5879ac58c3b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2965,31 +2965,29 @@ static int mp_irqdomain_create(int ioapic)
 	return 0;
 }
 
-void __init setup_IO_APIC(void)
+void __init setup_IO_APIC(bool xen_smp)
 {
 	int ioapic;
 
-	/*
-	 * calling enable_IO_APIC() is moved to setup_local_APIC for BP
-	 */
-	io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+	if (!xen_smp) {
+		apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
+		io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+
+		/* Set up IO-APIC IRQ routing. */
+		x86_init.mpparse.setup_ioapic_ids();
+		sync_Arb_IDs();
+	}
 
-	apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
 	for_each_ioapic(ioapic)
 		BUG_ON(mp_irqdomain_create(ioapic));
-
-	/*
- * Set up IO-APIC IRQ routing.
- */
-	x86_init.mpparse.setup_ioapic_ids();
-
-	sy

Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777

2014-12-19 Thread Jiang Liu
Hi Sander,
Found the root cause now, but still need some time to find
a solution for this issue.
xen_smp_prepare_cpus() doesn't call:
smpboot_setup_io_apic()->setup_IO_APIC()
So no irqdomain structure for IOAPIC created,  then mp_map_pin_to_irq()
fails at the very beginning.

The most simple solution is to revert following change, but it doesn't
seem the best solution. I will try to find a hook point to create
irqdomain for IOAPIC from xen_smp_prepare_cpus().
Regards!
Gerry

@@ -1034,13 +1035,8 @@ static int mp_map_pin_to_irq(u32 gsi, int idx,
int ioapic, int pin,
struct irq_domain *domain = mp_ioapic_irqdomain(ioapic);
struct mp_pin_info *info = mp_pin_info(ioapic, pin);

-   if (!domain) {
-   /*
-* Provide an identity mapping of gsi == irq except on truly
-* weird platforms that have non isa irqs in the first
16 gsis.
-*/
-   return gsi >= nr_legacy_irqs() ? gsi : gsi_top + gsi;
-   }
+   if (!domain)
+   return -1;

mutex_lock(&ioapic_mutex);



On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f61
> Author: Jiang Liu 
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
> x86, irq: Clean up irqdomain transition code
> 
> Now we have completely switched to irqdomain, so clean up transition code
> in IOAPIC drivers.
> 
> Signed-off-by: Jiang Liu 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tony Luck 
> Cc: Joerg Roedel 
> Cc: Paul Gortmaker 
> Cc: Greg Kroah-Hartman 
> Cc: Benjamin Herrenschmidt 
> Cc: Grant Likely 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: Randy Dunlap 
> Cc: Yinghai Lu 
> Link: 
> http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working 
> again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777

2014-12-19 Thread Jiang Liu
Hi Sander,
Sorry for the trouble, I will investigate on next Monday.
Regards!
Gerry

On 2014/12/19 21:16, Sander Eikelenboom wrote:
> Hi,
> 
> When running under Xen, ACPI powerbutton events don't work anymore, 
> there is no reaction when pressing the powerbutton.
> 
> On baremetal everything works fine, acpid gets the event and the 
> machine powers down perfectly. The machine is an Intel NUC.
>  
> Bisection has lead to:
> 
> b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit
> commit b81975eade8c6495f3c4d6746d22bdc95f61
> Author: Jiang Liu 
> Date:   Mon Jun 9 16:20:11 2014 +0800
> 
> x86, irq: Clean up irqdomain transition code
> 
> Now we have completely switched to irqdomain, so clean up transition code
> in IOAPIC drivers.
> 
> Signed-off-by: Jiang Liu 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tony Luck 
> Cc: Joerg Roedel 
> Cc: Paul Gortmaker 
> Cc: Greg Kroah-Hartman 
> Cc: Benjamin Herrenschmidt 
> Cc: Grant Likely 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: Randy Dunlap 
> Cc: Yinghai Lu 
> Link: 
> http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 
> 
> Reverting this specific commit on linux-tip (3.19-mw) gets things working 
> again under Xen.
> Kernel .config is attached.
> 
> --
> Sander
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [RFC Part4 v1 11/17] PCI, MSI: Rename __read_msi_msg() as __pci_read_msi_msg()

2014-11-09 Thread Jiang Liu
Rename __read_msi_msg() as __pci_read_msi_msg() and kill unused
read_msi_msg(). It's a preparation to separate generic MSI code
from PCI core.

Signed-off-by: Jiang Liu 
---
 arch/powerpc/platforms/pseries/msi.c |2 +-
 arch/x86/pci/xen.c   |2 +-
 drivers/pci/msi.c|9 +
 include/linux/msi.h  |3 +--
 4 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/msi.c 
b/arch/powerpc/platforms/pseries/msi.c
index 8ab5add4ac82..90f756d0f58f 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -476,7 +476,7 @@ again:
irq_set_msi_desc(virq, entry);
 
/* Read config space back so we can restore after reset */
-   __read_msi_msg(entry, &msg);
+   __pci_read_msi_msg(entry, &msg);
entry->msg = msg;
}
 
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 093f5f4272d3..a48ca2f8b93e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -229,7 +229,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
return 1;
 
list_for_each_entry(msidesc, &dev->msi_list, list) {
-   __read_msi_msg(msidesc, &msg);
+   __pci_read_msi_msg(msidesc, &msg);
pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
if (msg.data != XEN_PIRQ_MSI_DATA ||
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e1814f4be4b9..6011dfb475a1 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -243,7 +243,7 @@ void default_restore_msi_irqs(struct pci_dev *dev)
default_restore_msi_irq(dev, entry->irq);
 }
 
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
BUG_ON(entry->dev->current_state != PCI_D0);
 
@@ -273,13 +273,6 @@ void __read_msi_msg(struct msi_desc *entry, struct msi_msg 
*msg)
}
 }
 
-void read_msi_msg(unsigned int irq, struct msi_msg *msg)
-{
-   struct msi_desc *entry = irq_get_msi_desc(irq);
-
-   __read_msi_msg(entry, msg);
-}
-
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
if (entry->dev->current_state != PCI_D0) {
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 19502186a64d..4b0d070ff481 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -61,9 +61,8 @@ void msi_domain_deactivate(struct irq_domain *domain,
 
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
-void __read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void read_msi_msg(unsigned int irq, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
 
 /*
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [RFC Part4 v1 12/17] PCI, MSI: Rename __write_msi_msg() as __pci_write_msi_msg()

2014-11-09 Thread Jiang Liu
Rename __write_msi_msg() as __pci_write_msi_msg() to mark it as PCI
specific. Also define pci_write_msi_msg() as write_msi_msg() for easy
transition.

Signed-off-by: Jiang Liu 
---
 arch/x86/pci/xen.c  |2 +-
 drivers/pci/msi.c   |9 -
 include/linux/msi.h |3 ++-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index a48ca2f8b93e..1cfbe32c4b1c 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -240,7 +240,7 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type)
goto error;
}
xen_msi_compose_msg(dev, pirq, &msg);
-   __write_msi_msg(msidesc, &msg);
+   __pci_write_msi_msg(msidesc, &msg);
dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
} else {
dev_dbg(&dev->dev,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 6011dfb475a1..80be534df522 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -27,7 +27,6 @@ static int pci_msi_enable = 1;
 
 #define msix_table_size(flags) ((flags & PCI_MSIX_FLAGS_QSIZE) + 1)
 
-
 /* Arch hooks */
 
 int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
@@ -115,7 +114,7 @@ static void default_restore_msi_irq(struct pci_dev *dev, 
int irq)
}
 
if (entry)
-   __write_msi_msg(entry, &entry->msg);
+   __pci_write_msi_msg(entry, &entry->msg);
 }
 
 void __weak arch_restore_msi_irqs(struct pci_dev *dev)
@@ -273,7 +272,7 @@ void __pci_read_msi_msg(struct msi_desc *entry, struct 
msi_msg *msg)
}
 }
 
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
if (entry->dev->current_state != PCI_D0) {
/* Don't touch the hardware now */
@@ -314,7 +313,7 @@ void write_msi_msg(unsigned int irq, struct msi_msg *msg)
 {
struct msi_desc *entry = irq_get_msi_desc(irq);
 
-   __write_msi_msg(entry, msg);
+   __pci_write_msi_msg(entry, msg);
 }
 EXPORT_SYMBOL_GPL(write_msi_msg);
 
@@ -1085,7 +1084,7 @@ void pci_msi_write_msg(struct irq_data *irq_data, struct 
msi_msg *msg)
 * MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
 */
if (desc->irq == irq_data->irq)
-   __write_msi_msg(desc, msg);
+   __pci_write_msi_msg(desc, msg);
 }
 
 /*
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 4b0d070ff481..5639970db71d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -62,8 +62,9 @@ void msi_domain_deactivate(struct irq_domain *domain,
 #ifdef CONFIG_PCI_MSI
 /* Helper functions */
 void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
-void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+#define pci_write_msi_msg  write_msi_msg
 
 /*
  * The arch hooks to setup up msi irqs. Those functions are
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel