[patch 0/4] XEN: Interrupt cleanups

[patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

Jeremy,

the following series converts the interrupt chips of XEN to the new
chip functions and the last patches replace the xen private resume
hackery.

The first two patches have no dependencies.

The last two need the modification to the generic interrupt layer. I
could either carry them through the genirq tree with your
acked-tested-whatever-by or I provide you a branch to pull that change
from. I need the genirq change local as it conflicts with other patches
in the pipeline. Either way works fine.

Thanks,

	tglx

[patch 1/4] xen: Remove stale irq_chip.end

[Thomas Gleixner]

[-- Attachment #1: xen-remove-stale-irq_chip-end.patch --]
[-- Type: text/plain, Size: 1050 bytes --]

irq_chip.end got obsolete with the removal of __do_IRQ()

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/xen/events.c |   18 ------------------
 1 file changed, 18 deletions(-)

Index: linux-next/drivers/xen/events.c
===================================================================
--- linux-next.orig/drivers/xen/events.c
+++ linux-next/drivers/xen/events.c
@@ -551,23 +551,6 @@ static void ack_pirq(unsigned int irq)
 	}
 }
 
-static void end_pirq(unsigned int irq)
-{
-	int evtchn = evtchn_from_irq(irq);
-	struct irq_desc *desc = irq_to_desc(irq);
-
-	if (WARN_ON(!desc))
-		return;
-
-	if ((desc->status & (IRQ_DISABLED|IRQ_PENDING)) ==
-	    (IRQ_DISABLED|IRQ_PENDING)) {
-		shutdown_pirq(irq);
-	} else if (VALID_EVTCHN(evtchn)) {
-		unmask_evtchn(evtchn);
-		pirq_unmask_notify(irq);
-	}
-}
-
 static int find_irq_by_gsi(unsigned gsi)
 {
 	int irq;
@@ -1504,7 +1487,6 @@ static struct irq_chip xen_pirq_chip __r
 	.mask		= disable_pirq,
 
 	.ack		= ack_pirq,
-	.end		= end_pirq,
 
 	.set_affinity	= set_affinity_irq,
 

[patch 2/4] xen: Switch to new irq_chip functions

[Thomas Gleixner]

[-- Attachment #1: xen-switch-to-new-irq-functions.patch --]
[-- Type: text/plain, Size: 5636 bytes --]

Convert Xen to the new irq_chip functions. Brings us closer to enable
CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/xen/events.c |   97 +++++++++++++++++++++++++++------------------------
 1 file changed, 52 insertions(+), 45 deletions(-)

Index: linux-next/drivers/xen/events.c
===================================================================
--- linux-next.orig/drivers/xen/events.c
+++ linux-next/drivers/xen/events.c
@@ -277,7 +277,7 @@ static void bind_evtchn_to_cpu(unsigned 
 
 	BUG_ON(irq == -1);
 #ifdef CONFIG_SMP
-	cpumask_copy(irq_to_desc(irq)->affinity, cpumask_of(cpu));
+	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
 	clear_bit(chn, cpu_evtchn_mask(cpu_from_irq(irq)));
@@ -294,7 +294,7 @@ static void init_evtchn_cpu_bindings(voi
 
 	/* By default all event channels notify CPU#0. */
 	for_each_irq_desc(i, desc) {
-		cpumask_copy(desc->affinity, cpumask_of(0));
+		cpumask_copy(desc->irq_data.affinity, cpumask_of(0));
 	}
 #endif
 
@@ -470,7 +470,7 @@ static bool probing_irq(int irq)
 	return desc && desc->action == NULL;
 }
 
-static unsigned int startup_pirq(unsigned int irq)
+static unsigned int __startup_pirq(unsigned int irq)
 {
 	struct evtchn_bind_pirq bind_pirq;
 	struct irq_info *info = info_for_irq(irq);
@@ -508,9 +508,15 @@ out:
 	return 0;
 }
 
-static void shutdown_pirq(unsigned int irq)
+static unsigned int startup_pirq(struct irq_data *data)
+{
+	return __startup_pirq(data->irq);
+}
+
+static void shutdown_pirq(struct irq_data *data)
 {
 	struct evtchn_close close;
+	unsigned int irq = data->irq;
 	struct irq_info *info = info_for_irq(irq);
 	int evtchn = evtchn_from_irq(irq);
 
@@ -530,20 +536,20 @@ static void shutdown_pirq(unsigned int i
 	info->evtchn = 0;
 }
 
-static void enable_pirq(unsigned int irq)
+static void enable_pirq(struct irq_data *data)
 {
-	startup_pirq(irq);
+	startup_pirq(data);
 }
 
-static void disable_pirq(unsigned int irq)
+static void disable_pirq(struct irq_data *data)
 {
 }
 
-static void ack_pirq(unsigned int irq)
+static void ack_pirq(struct irq_data *data)
 {
-	int evtchn = evtchn_from_irq(irq);
+	int evtchn = evtchn_from_irq(data->irq);
 
-	move_native_irq(irq);
+	irq_move_irq(data);
 
 	if (VALID_EVTCHN(evtchn)) {
 		mask_evtchn(evtchn);
@@ -1211,11 +1217,12 @@ static int rebind_irq_to_cpu(unsigned ir
 	return 0;
 }
 
-static int set_affinity_irq(unsigned irq, const struct cpumask *dest)
+static int set_affinity_irq(struct irq_data *data, const struct cpumask *dest,
+			    bool force)
 {
 	unsigned tcpu = cpumask_first(dest);
 
-	return rebind_irq_to_cpu(irq, tcpu);
+	return rebind_irq_to_cpu(data->irq, tcpu);
 }
 
 int resend_irq_on_evtchn(unsigned int irq)
@@ -1234,35 +1241,35 @@ int resend_irq_on_evtchn(unsigned int ir
 	return 1;
 }
 
-static void enable_dynirq(unsigned int irq)
+static void enable_dynirq(struct irq_data *data)
 {
-	int evtchn = evtchn_from_irq(irq);
+	int evtchn = evtchn_from_irq(data->irq);
 
 	if (VALID_EVTCHN(evtchn))
 		unmask_evtchn(evtchn);
 }
 
-static void disable_dynirq(unsigned int irq)
+static void disable_dynirq(struct irq_data *data)
 {
-	int evtchn = evtchn_from_irq(irq);
+	int evtchn = evtchn_from_irq(data->irq);
 
 	if (VALID_EVTCHN(evtchn))
 		mask_evtchn(evtchn);
 }
 
-static void ack_dynirq(unsigned int irq)
+static void ack_dynirq(struct irq_data *data)
 {
-	int evtchn = evtchn_from_irq(irq);
+	int evtchn = evtchn_from_irq(data->irq);
 
-	move_masked_irq(irq);
+	move_masked_irq(data->irq);
 
 	if (VALID_EVTCHN(evtchn))
 		unmask_evtchn(evtchn);
 }
 
-static int retrigger_dynirq(unsigned int irq)
+static int retrigger_dynirq(struct irq_data *data)
 {
-	int evtchn = evtchn_from_irq(irq);
+	int evtchn = evtchn_from_irq(data->irq);
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int ret = 0;
 
@@ -1311,7 +1318,7 @@ static void restore_cpu_pirqs(void)
 
 		printk(KERN_DEBUG "xen: --> irq=%d, pirq=%d\n", irq, map_irq.pirq);
 
-		startup_pirq(irq);
+		__startup_pirq(irq);
 	}
 }
 
@@ -1463,44 +1470,44 @@ void xen_irq_resume(void)
 }
 
 static struct irq_chip xen_dynamic_chip __read_mostly = {
-	.name		= "xen-dyn",
+	.name			= "xen-dyn",
 
-	.disable	= disable_dynirq,
-	.mask		= disable_dynirq,
-	.unmask		= enable_dynirq,
-
-	.eoi		= ack_dynirq,
-	.set_affinity	= set_affinity_irq,
-	.retrigger	= retrigger_dynirq,
+	.irq_disable		= disable_dynirq,
+	.irq_mask		= disable_dynirq,
+	.irq_unmask		= enable_dynirq,
+
+	.irq_eoi		= ack_dynirq,
+	.irq_set_affinity	= set_affinity_irq,
+	.irq_retrigger		= retrigger_dynirq,
 };
 
 static struct irq_chip xen_pirq_chip __read_mostly = {
-	.name		= "xen-pirq",
+	.name			= "xen-pirq",
 
-	.startup	= startup_pirq,
-	.shutdown	= shutdown_pirq,
+	.irq_startup		= startup_pirq,
+	.irq_shutdown		= shutdown_pirq,
 
-	.enable		= enable_pirq,
-	.unmask		= enable_pirq,
+	.irq_enable		= enable_pirq,
+	.irq_unmask		= enable_pirq,
 
-	.disable	= disable_pirq,
-	.mask		= disable_pirq,
+	.irq_disable		= disable_pirq,
+	.irq_mask		= disable_pirq,
 
-	.ack		= ack_pirq,
+	.irq_ack		= ack_pirq,
 
-	.set_affinity	= set_affinity_irq,
+	.irq_set_affinity	= set_affinity_irq,
 
-	.retrigger	= retrigger_dynirq,
+	.irq_retrigger		= retrigger_dynirq,
 };
 
 static struct irq_chip xen_percpu_chip __read_mostly = {
-	.name		= "xen-percpu",
+	.name			= "xen-percpu",
 
-	.disable	= disable_dynirq,
-	.mask		= disable_dynirq,
-	.unmask		= enable_dynirq,
+	.irq_disable		= disable_dynirq,
+	.irq_mask		= disable_dynirq,
+	.irq_unmask		= enable_dynirq,
 
-	.ack		= ack_dynirq,
+	.irq_ack		= ack_dynirq,
 };
 
 int xen_set_callback_via(uint64_t via)

[patch 3/4] genirq: Add IRQF_FORCE_RESUME

[Thomas Gleixner]

[-- Attachment #1: genirq-add-force-enable-on-resume.patch --]
[-- Type: text/plain, Size: 3150 bytes --]

Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the
resume path. Add a flag to force the reenabling in the resume code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/interrupt.h |    3 ++-
 include/linux/irq.h       |    4 +++-
 kernel/irq/manage.c       |   11 ++++++++++-
 kernel/irq/pm.c           |    3 ---
 4 files changed, 15 insertions(+), 6 deletions(-)

Index: linux-next/include/linux/interrupt.h
===================================================================
--- linux-next.orig/include/linux/interrupt.h
+++ linux-next/include/linux/interrupt.h
@@ -57,7 +57,7 @@
  *                Used by threaded interrupts which need to keep the
  *                irq line disabled until the threaded handler has been run.
  * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
- *
+ * IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -69,6 +69,7 @@
 #define IRQF_IRQPOLL		0x00001000
 #define IRQF_ONESHOT		0x00002000
 #define IRQF_NO_SUSPEND		0x00004000
+#define IRQF_FORCE_RESUME	0x00008000
 
 #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND)
 
Index: linux-next/include/linux/irq.h
===================================================================
--- linux-next.orig/include/linux/irq.h
+++ linux-next/include/linux/irq.h
@@ -71,10 +71,12 @@ typedef	void (*irq_flow_handler_t)(unsig
 #define IRQ_SUSPENDED		0x04000000	/* IRQ has gone through suspend sequence */
 #define IRQ_ONESHOT		0x08000000	/* IRQ is not unmasked after hardirq */
 #define IRQ_NESTED_THREAD	0x10000000	/* IRQ is nested into another, no own handler thread */
+#define IRQ_FORCE_SUSPEND	0x20000000	/* Ignore IRQF_NO_SUSPEND */
 
 #define IRQF_MODIFY_MASK	\
 	(IRQ_TYPE_SENSE_MASK | IRQ_NOPROBE | IRQ_NOREQUEST | \
-	 IRQ_NOAUTOEN | IRQ_MOVE_PCNTXT | IRQ_LEVEL)
+	 IRQ_NOAUTOEN | IRQ_MOVE_PCNTXT | IRQ_LEVEL \
+	 IRQ_FORCE_SUSPEND)
 
 #ifdef CONFIG_IRQ_PER_CPU
 # define CHECK_IRQ_PER_CPU(var) ((var) & IRQ_PER_CPU)
Index: linux-next/kernel/irq/manage.c
===================================================================
--- linux-next.orig/kernel/irq/manage.c
+++ linux-next/kernel/irq/manage.c
@@ -359,8 +359,17 @@ EXPORT_SYMBOL(disable_irq);
 
 void __enable_irq(struct irq_desc *desc, unsigned int irq, bool resume)
 {
-	if (resume)
+	if (resume) {
+		if (!(desc->status & IRQ_SUSPENDED)) {
+			if (!desc->action)
+				return;
+			if (!(desc->action->flags & IRQF_FORCE_RESUME))
+				return;
+			/* Pretend that it got disabled ! */
+			desc->depth++;
+		}
 		desc->status &= ~IRQ_SUSPENDED;
+	}
 
 	switch (desc->depth) {
 	case 0:
Index: linux-next/kernel/irq/pm.c
===================================================================
--- linux-next.orig/kernel/irq/pm.c
+++ linux-next/kernel/irq/pm.c
@@ -53,9 +53,6 @@ void resume_device_irqs(void)
 	for_each_irq_desc(irq, desc) {
 		unsigned long flags;
 
-		if (!(desc->status & IRQ_SUSPENDED))
-			continue;
-
 		raw_spin_lock_irqsave(&desc->lock, flags);
 		__enable_irq(desc, irq, true);
 		raw_spin_unlock_irqrestore(&desc->lock, flags);

[patch 4/4] xen: Use IRQF_FORCE_RESUME

[Thomas Gleixner]

[-- Attachment #1: xen-use-IRQF_FORCE_RESUME.patch --]
[-- Type: text/plain, Size: 1403 bytes --]

Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
walk through the interrupt descriptors.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 drivers/xen/events.c |   20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

Index: linux-next/drivers/xen/events.c
===================================================================
--- linux-next.orig/drivers/xen/events.c
+++ linux-next/drivers/xen/events.c
@@ -973,7 +973,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
 	if (irq < 0)
 		return irq;
 
-	irqflags |= IRQF_NO_SUSPEND;
+	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
 	if (retval != 0) {
 		unbind_from_irq(irq);
@@ -1429,7 +1429,6 @@ void xen_poll_irq(int irq)
 void xen_irq_resume(void)
 {
 	unsigned int cpu, irq, evtchn;
-	struct irq_desc *desc;
 
 	init_evtchn_cpu_bindings();
 
@@ -1449,23 +1448,6 @@ void xen_irq_resume(void)
 		restore_cpu_ipis(cpu);
 	}
 
-	/*
-	 * Unmask any IRQF_NO_SUSPEND IRQs which are enabled. These
-	 * are not handled by the IRQ core.
-	 */
-	for_each_irq_desc(irq, desc) {
-		if (!desc->action || !(desc->action->flags & IRQF_NO_SUSPEND))
-			continue;
-		if (desc->status & IRQ_DISABLED)
-			continue;
-
-		evtchn = evtchn_from_irq(irq);
-		if (evtchn == -1)
-			continue;
-
-		unmask_evtchn(evtchn);
-	}
-
 	restore_cpu_pirqs();
 }
 

Re: [patch 2/4] xen: Switch to new irq_chip functions

[Ian Campbell]

On Sat, 2011-02-05 at 20:08 +0000, Thomas Gleixner wrote:
> 
> -static void ack_pirq(unsigned int irq)
> +static void ack_pirq(struct irq_data *data)
>  {
> -       int evtchn = evtchn_from_irq(irq);
> +       int evtchn = evtchn_from_irq(data->irq);
>  
> -       move_native_irq(irq);
> +       irq_move_irq(data); 

I tried to test with Linus latest but with this patch:

/local/scratch/ianc/devel/kernels/linux-2.6/drivers/xen/events.c: In function 'ack_pirq':
/local/scratch/ianc/devel/kernels/linux-2.6/drivers/xen/events.c:568: error: implicit declaration of function 'irq_move_irq'

I can't find irq_move_irq in any of the tip.git branches (incl. master,
auto-latest and .*irq.*), via google or in any of the other conversion
patches you posted for other arches. Am I just looking in the wrong
places or was this a mistake?

For now I went with the following sort-of-reversion to allow me to
continue:

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 65f05e2..6f5dd38 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -565,7 +565,7 @@ static void ack_pirq(struct irq_data *data)
 {
 	int evtchn = evtchn_from_irq(data->irq);
 
-	irq_move_irq(data);
+	move_native_irq(data->irq);
 
 	if (VALID_EVTCHN(evtchn)) {
 		mask_evtchn(evtchn);

Ian.

Re: [patch 2/4] xen: Switch to new irq_chip functions

[Thomas Gleixner]

On Mon, 7 Feb 2011, Ian Campbell wrote:

> On Sat, 2011-02-05 at 20:08 +0000, Thomas Gleixner wrote:
> > 
> > -static void ack_pirq(unsigned int irq)
> > +static void ack_pirq(struct irq_data *data)
> >  {
> > -       int evtchn = evtchn_from_irq(irq);
> > +       int evtchn = evtchn_from_irq(data->irq);
> >  
> > -       move_native_irq(irq);
> > +       irq_move_irq(data); 
> 
> I tried to test with Linus latest but with this patch:
> 
> /local/scratch/ianc/devel/kernels/linux-2.6/drivers/xen/events.c: In function 'ack_pirq':
> /local/scratch/ianc/devel/kernels/linux-2.6/drivers/xen/events.c:568: error: implicit declaration of function 'irq_move_irq'
> 
> I can't find irq_move_irq in any of the tip.git branches (incl. master,
> auto-latest and .*irq.*), via google or in any of the other conversion
> patches you posted for other arches. Am I just looking in the wrong
> places or was this a mistake?
> 
> For now I went with the following sort-of-reversion to allow me to
> continue:
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 65f05e2..6f5dd38 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -565,7 +565,7 @@ static void ack_pirq(struct irq_data *data)
>  {
>  	int evtchn = evtchn_from_irq(data->irq);
>  
> -	irq_move_irq(data);
> +	move_native_irq(data->irq);

Sorry, had another patch applied before that. Did not recheck before
sending it. Yes, that's the correct resolution.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Jeremy Fitzhardinge]

On 02/05/2011 12:08 PM, Thomas Gleixner wrote:
> the following series converts the interrupt chips of XEN to the new
> chip functions and the last patches replace the xen private resume
> hackery.
>
> The first two patches have no dependencies.
>
> The last two need the modification to the generic interrupt layer. I
> could either carry them through the genirq tree with your
> acked-tested-whatever-by or I provide you a branch to pull that change
> from. I need the genirq change local as it conflicts with other patches
> in the pipeline. Either way works fine.

Hi Thomas,

Thanks very much for looking at this.  IanC also has some patches to
clean up the Xen interrupt stuff to get rid of the local hacks, so I'll
let him work out how to reconcile the two sets of work (ah, I see he's
already replied).

[Read patches]

It doesn't look like there's any functional overlap at all, since his
patches are concerned with using the core irq allocator rather than a
private one, so that's OK.

Anyway, I'll let Ian do the ack.

    J

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

Jeremy,

On Mon, 7 Feb 2011, Jeremy Fitzhardinge wrote:
> On 02/05/2011 12:08 PM, Thomas Gleixner wrote:
> > the following series converts the interrupt chips of XEN to the new
> > chip functions and the last patches replace the xen private resume
> > hackery.
> >
> > The first two patches have no dependencies.
> >
> > The last two need the modification to the generic interrupt layer. I
> > could either carry them through the genirq tree with your
> > acked-tested-whatever-by or I provide you a branch to pull that change
> > from. I need the genirq change local as it conflicts with other patches
> > in the pipeline. Either way works fine.
> 
> Hi Thomas,
> 
> Thanks very much for looking at this.  IanC also has some patches to
> clean up the Xen interrupt stuff to get rid of the local hacks, so I'll
> let him work out how to reconcile the two sets of work (ah, I see he's
> already replied).
> 
> [Read patches]
> 
> It doesn't look like there's any functional overlap at all, since his
> patches are concerned with using the core irq allocator rather than a
> private one, so that's OK.
> 
> Anyway, I'll let Ian do the ack.

Ok. The irq_chip conversion is mostly mechanical, but I'm really
concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
resp. Ian could give that a test ride. That would allow me to cleanup
stuff in the core code.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Sat, 2011-02-05 at 20:08 +0000, Thomas Gleixner wrote: 
> Jeremy,
> 
> the following series converts the interrupt chips of XEN to the new
> chip functions and the last patches replace the xen private resume
> hackery.
> 
> The first two patches have no dependencies.
> 
> The last two need the modification to the generic interrupt layer. I
> could either carry them through the genirq tree with your
> acked-tested-whatever-by or I provide you a branch to pull that change
> from. I need the genirq change local as it conflicts with other patches
> in the pipeline. Either way works fine.

I definitely like IRQF_FORCE_RESUME bits, clearly much better than the
current solution.

I applied the complete series applied on top of current Linus tree (with
fixlet from my reply to 2/4 and a little reject fixup in irq.h from
3/4). 

It appears that with all 4 patches applied IPIs aren't getting
resumed/unmasked/something else after a migration.

Adding an irq_enable hook to the relevant irq_chip didn't fix it and I
didn't get a chance to dig any deeper this evening.

I'll look a bit closer tomorrow and get back to you.

Ian. 

Re: [patch 0/4] XEN: Interrupt cleanups

[Jeremy Fitzhardinge]

On 02/07/2011 01:33 PM, Thomas Gleixner wrote:
> Ok. The irq_chip conversion is mostly mechanical, but I'm really
> concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
> resp. Ian could give that a test ride. That would allow me to cleanup
> stuff in the core code.

Ian notes: "tglx's 4 patch interrupt cleanup series on LKML causes some
oddities on PV migration. Will dig further tomorrow..."

So it looks like there's still something amiss.

    J

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Mon, 2011-02-07 at 13:57 -0800, Jeremy Fitzhardinge wrote:
> On 02/07/2011 01:33 PM, Thomas Gleixner wrote:
> > Ok. The irq_chip conversion is mostly mechanical, but I'm really
> > concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
> > resp. Ian could give that a test ride. That would allow me to cleanup
> > stuff in the core code.
> 
> Ian notes: "tglx's 4 patch interrupt cleanup series on LKML causes some
> oddities on PV migration. Will dig further tomorrow..."
> 
> So it looks like there's still something amiss.

The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via
IRQF_TIMER. The following fixed things for me (probably belongs in your
patch 4/4).

With this fixlet PV guest migration works just fine. I also booted the
entire series as a dom0 kernel and it appeared fine.

I also tested alongside the cleanup patches Jeremy mentioned before and
as expected there is no interaction.

So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
(below), the entire series is:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 067759e..2e2d370 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -397,7 +397,9 @@ void xen_setup_timer(int cpu)
 		name = "<timer kasprintf failed>";
 
 	irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt,
-				      IRQF_DISABLED|IRQF_PERCPU|IRQF_NOBALANCING|IRQF_TIMER,
+				      IRQF_DISABLED|IRQF_PERCPU|
+				      IRQF_NOBALANCING|IRQF_TIMER|
+				      IRQF_FORCE_RESUME,
 				      name, NULL);
 
 	evt = &per_cpu(xen_clock_events, cpu);

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

On Tue, 8 Feb 2011, Ian Campbell wrote:
> On Mon, 2011-02-07 at 13:57 -0800, Jeremy Fitzhardinge wrote:
> > On 02/07/2011 01:33 PM, Thomas Gleixner wrote:
> > > Ok. The irq_chip conversion is mostly mechanical, but I'm really
> > > concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
> > > resp. Ian could give that a test ride. That would allow me to cleanup
> > > stuff in the core code.
> > 
> > Ian notes: "tglx's 4 patch interrupt cleanup series on LKML causes some
> > oddities on PV migration. Will dig further tomorrow..."
> > 
> > So it looks like there's still something amiss.
> 
> The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via
> IRQF_TIMER. The following fixed things for me (probably belongs in your
> patch 4/4).
> 
> With this fixlet PV guest migration works just fine. I also booted the
> entire series as a dom0 kernel and it appeared fine.
> 
> I also tested alongside the cleanup patches Jeremy mentioned before and
> as expected there is no interaction.
> 
> So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> (below), the entire series is:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Cool. So what's the best way to proceed ? That code is not yet in
linus tree, right ?

So I guess the best way is that I add the core changes to a rc-4 based
branch and you can pull it in and apply the whole xen stuff to your
own tree.

I base my pending patches on top of that so it wont be any problem
when merging the stuff together in next or linus later.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> On Tue, 8 Feb 2011, Ian Campbell wrote:
> > On Mon, 2011-02-07 at 13:57 -0800, Jeremy Fitzhardinge wrote:
> > > On 02/07/2011 01:33 PM, Thomas Gleixner wrote:
> > > > Ok. The irq_chip conversion is mostly mechanical, but I'm really
> > > > concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
> > > > resp. Ian could give that a test ride. That would allow me to cleanup
> > > > stuff in the core code.
> > > 
> > > Ian notes: "tglx's 4 patch interrupt cleanup series on LKML causes some
> > > oddities on PV migration. Will dig further tomorrow..."
> > > 
> > > So it looks like there's still something amiss.
> > 
> > The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via
> > IRQF_TIMER. The following fixed things for me (probably belongs in your
> > patch 4/4).
> > 
> > With this fixlet PV guest migration works just fine. I also booted the
> > entire series as a dom0 kernel and it appeared fine.
> > 
> > I also tested alongside the cleanup patches Jeremy mentioned before and
> > as expected there is no interaction.
> > 
> > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > (below), the entire series is:
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Cool. So what's the best way to proceed ? That code is not yet in
> linus tree, right ?

Correct.

> So I guess the best way is that I add the core changes to a rc-4 based
> branch and you can pull it in and apply the whole xen stuff to your
> own tree.

My existing cleanup patches are in Konrad's tree (which is in linux-next
etc) so that probably makes most sense as a home for this series. So
unless Konrad has any objections I think it makes sense to pull your
core changes into that branch and then apply your Xen bits on top.

Konrad's branch with my stuff is:
  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework

Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
== http://thread.gmane.org/gmane.linux.kernel/1096437

> I base my pending patches on top of that so it wont be any problem
> when merging the stuff together in next or linus later.

I don't think there will be much trouble with overlap between these and
any Xen events.c changes for the next merge window but what you suggest
should remove the risk.

Ian.

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

On Tue, 8 Feb 2011, Ian Campbell wrote:
> On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > > (below), the entire series is:
> > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Cool. So what's the best way to proceed ? That code is not yet in
> > linus tree, right ?
> 
> Correct.
> 
> > So I guess the best way is that I add the core changes to a rc-4 based
> > branch and you can pull it in and apply the whole xen stuff to your
> > own tree.
> 
> My existing cleanup patches are in Konrad's tree (which is in linux-next
> etc) so that probably makes most sense as a home for this series. So
> unless Konrad has any objections I think it makes sense to pull your
> core changes into that branch and then apply your Xen bits on top.
> 
> Konrad's branch with my stuff is:
>   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework
> 
> Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
> == http://thread.gmane.org/gmane.linux.kernel/1096437
> 
> > I base my pending patches on top of that so it wont be any problem
> > when merging the stuff together in next or linus later.
> 
> I don't think there will be much trouble with overlap between these and
> any Xen events.c changes for the next merge window but what you suggest
> should remove the risk.

Yes, and please talk to me next time before you hack around in the
guts of the interrupt code. I noticed just because I was skimming
-next, and that really conflicts with major cleanups I'm doing. If
there is a shortcoming in the generic code, then let me know.

Core change is in 

git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Konrad Rzeszutek Wilk]

On Tue, Feb 08, 2011 at 04:39:58PM +0100, Thomas Gleixner wrote:
> On Tue, 8 Feb 2011, Ian Campbell wrote:
> > On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> > > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > > > (below), the entire series is:
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Cool. So what's the best way to proceed ? That code is not yet in
> > > linus tree, right ?
> > 
> > Correct.
> > 
> > > So I guess the best way is that I add the core changes to a rc-4 based
> > > branch and you can pull it in and apply the whole xen stuff to your
> > > own tree.
> > 
> > My existing cleanup patches are in Konrad's tree (which is in linux-next
> > etc) so that probably makes most sense as a home for this series. So
> > unless Konrad has any objections I think it makes sense to pull your
> > core changes into that branch and then apply your Xen bits on top.

Ok. Pulled in these patches and stuck Ack-ed by Ian on them.
> > 
> > Konrad's branch with my stuff is:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework
> > 
> > Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
> > == http://thread.gmane.org/gmane.linux.kernel/1096437
> > 
> > > I base my pending patches on top of that so it wont be any problem
> > > when merging the stuff together in next or linus later.
> > 
> > I don't think there will be much trouble with overlap between these and
> > any Xen events.c changes for the next merge window but what you suggest
> > should remove the risk.
> 
> Yes, and please talk to me next time before you hack around in the
> guts of the interrupt code. I noticed just because I was skimming
> -next, and that really conflicts with major cleanups I'm doing. If
> there is a shortcoming in the generic code, then let me know.

<scratches his head> The rework was in Xen code not in generic, and
the only generic changes that are in there ..  are your code?

This is what I've in the stable/irq.rework and also in the linux-next
branch. Please tell me if I messed up.

Ian Campbell (7):
      xen: handled remapped IRQs when enabling a pcifront PCI device.
      xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
      xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
      xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
      xen: events: do not free legacy IRQs
      xen: Fix compile error introduced by "switch to new irq_chip functions"
      xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.

Konrad Rzeszutek Wilk (2):
      xen/irq: Cleanup the find_unbound_irq
      xen/irq: Don't fall over when nr_irqs_gsi > nr_irqs.

Thomas Gleixner (3):
      xen: Remove stale irq_chip.end
      xen: Switch to new irq_chip functions
      genirq: Add IRQF_FORCE_RESUME

> 
> Core change is in 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen

<nods> Pulled that in my branch.
> 
> Thanks,
> 
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/4] XEN: Interrupt cleanups

[Konrad Rzeszutek Wilk]

> Core change is in 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen

I just noticed that the patch you put in there differs from the
one you posted: "genirq: Add IRQF_FORCE_RESUME". You missed the
changes in include/linux/interrupt.h for the IRQF_MODIFY_MASK.

Was that intentional?

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Tue, 2011-02-08 at 15:39 +0000, Thomas Gleixner wrote:
> On Tue, 8 Feb 2011, Ian Campbell wrote:
> > On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> > > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > > > (below), the entire series is:
> > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > 
> > > Cool. So what's the best way to proceed ? That code is not yet in
> > > linus tree, right ?
> > 
> > Correct.
> > 
> > > So I guess the best way is that I add the core changes to a rc-4 based
> > > branch and you can pull it in and apply the whole xen stuff to your
> > > own tree.
> > 
> > My existing cleanup patches are in Konrad's tree (which is in linux-next
> > etc) so that probably makes most sense as a home for this series. So
> > unless Konrad has any objections I think it makes sense to pull your
> > core changes into that branch and then apply your Xen bits on top.
> > 
> > Konrad's branch with my stuff is:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework
> > 
> > Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
> > == http://thread.gmane.org/gmane.linux.kernel/1096437
> > 
> > > I base my pending patches on top of that so it wont be any problem
> > > when merging the stuff together in next or linus later.
> > 
> > I don't think there will be much trouble with overlap between these and
> > any Xen events.c changes for the next merge window but what you suggest
> > should remove the risk.
> 
> Yes, and please talk to me next time before you hack around in the
> guts of the interrupt code. I noticed just because I was skimming
> -next, and that really conflicts with major cleanups I'm doing. If
> there is a shortcoming in the generic code, then let me know.

Will do in the future, sorry about that.

Ian.

> 
> Core change is in 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen
> 
> Thanks,
> 
> 	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 08, 2011 at 04:39:58PM +0100, Thomas Gleixner wrote:
> > On Tue, 8 Feb 2011, Ian Campbell wrote:
> > > On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> > > > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > > > > (below), the entire series is:
> > > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > > 
> > > > Cool. So what's the best way to proceed ? That code is not yet in
> > > > linus tree, right ?
> > > 
> > > Correct.
> > > 
> > > > So I guess the best way is that I add the core changes to a rc-4 based
> > > > branch and you can pull it in and apply the whole xen stuff to your
> > > > own tree.
> > > 
> > > My existing cleanup patches are in Konrad's tree (which is in linux-next
> > > etc) so that probably makes most sense as a home for this series. So
> > > unless Konrad has any objections I think it makes sense to pull your
> > > core changes into that branch and then apply your Xen bits on top.
> 
> Ok. Pulled in these patches and stuck Ack-ed by Ian on them.
> > > 
> > > Konrad's branch with my stuff is:
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework
> > > 
> > > Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
> > > == http://thread.gmane.org/gmane.linux.kernel/1096437
> > > 
> > > > I base my pending patches on top of that so it wont be any problem
> > > > when merging the stuff together in next or linus later.
> > > 
> > > I don't think there will be much trouble with overlap between these and
> > > any Xen events.c changes for the next merge window but what you suggest
> > > should remove the risk.
> > 
> > Yes, and please talk to me next time before you hack around in the
> > guts of the interrupt code. I noticed just because I was skimming
> > -next, and that really conflicts with major cleanups I'm doing. If
> > there is a shortcoming in the generic code, then let me know.
> 
> <scratches his head> The rework was in Xen code not in generic, and
> the only generic changes that are in there ..  are your code?

I think Thomas was referring to the "unmask because the core didn't do
it for us" hack I added a while back which he is replacing with
IRQF_FORCE_RESUME.

Ian.

> 
> This is what I've in the stable/irq.rework and also in the linux-next
> branch. Please tell me if I messed up.
> 
> Ian Campbell (7):
>       xen: handled remapped IRQs when enabling a pcifront PCI device.
>       xen:events: move find_unbound_irq inside CONFIG_PCI_MSI
>       xen: events: add xen_allocate_irq_{dynamic, gsi} and xen_free_irq
>       xen: events: allocate GSIs and dynamic IRQs from separate IRQ ranges.
>       xen: events: do not free legacy IRQs
>       xen: Fix compile error introduced by "switch to new irq_chip functions"
>       xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.
> 
> Konrad Rzeszutek Wilk (2):
>       xen/irq: Cleanup the find_unbound_irq
>       xen/irq: Don't fall over when nr_irqs_gsi > nr_irqs.
> 
> Thomas Gleixner (3):
>       xen: Remove stale irq_chip.end
>       xen: Switch to new irq_chip functions
>       genirq: Add IRQF_FORCE_RESUME
> 
> > 
> > Core change is in 
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen
> 
> <nods> Pulled that in my branch.
> > 
> > Thanks,
> > 
> > 	tglx
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

on Tue, 8 Feb 2011, Konrad Rzeszutek Wilk wrote:

> On Tue, Feb 08, 2011 at 04:39:58PM +0100, Thomas Gleixner wrote:
> > On Tue, 8 Feb 2011, Ian Campbell wrote:
> > > On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> > > > > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > > > > (below), the entire series is:
> > > > > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > > > 
> > > > Cool. So what's the best way to proceed ? That code is not yet in
> > > > linus tree, right ?
> > > 
> > > Correct.
> > > 
> > > > So I guess the best way is that I add the core changes to a rc-4 based
> > > > branch and you can pull it in and apply the whole xen stuff to your
> > > > own tree.
> > > 
> > > My existing cleanup patches are in Konrad's tree (which is in linux-next
> > > etc) so that probably makes most sense as a home for this series. So
> > > unless Konrad has any objections I think it makes sense to pull your
> > > core changes into that branch and then apply your Xen bits on top.
> 
> Ok. Pulled in these patches and stuck Ack-ed by Ian on them.
> > > 
> > > Konrad's branch with my stuff is:
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/irq.rework
> > > 
> > > Konrad, this thread starts at <20110205200108.921707839@linutronix.de>
> > > == http://thread.gmane.org/gmane.linux.kernel/1096437
> > > 
> > > > I base my pending patches on top of that so it wont be any problem
> > > > when merging the stuff together in next or linus later.
> > > 
> > > I don't think there will be much trouble with overlap between these and
> > > any Xen events.c changes for the next merge window but what you suggest
> > > should remove the risk.
> > 
> > Yes, and please talk to me next time before you hack around in the
> > guts of the interrupt code. I noticed just because I was skimming
> > -next, and that really conflicts with major cleanups I'm doing. If
> > there is a shortcoming in the generic code, then let me know.
> 
> <scratches his head> The rework was in Xen code not in generic, and
> the only generic changes that are in there ..  are your code?

The point is:

If you play with generic irq code in Xen in some weird way then you
basically block me to cleanup something in the core code w/o breaking
Xen. I wanted to move IRQ_SUSPENDED to a different field and
accidentally noticed that Xen was fiddling with in -next.

So that's what I'm grumpy about. You hack away in Xen and claim it's
confined to your code, while in reality it is _NOT_.

Again, if there is a problem with the generic code then talk to me.

That's going to be impossible anyway when I'm done with the
encapsulation.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

On Tue, 8 Feb 2011, Konrad Rzeszutek Wilk wrote:

> > Core change is in 
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/for-xen
> 
> I just noticed that the patch you put in there differs from the
> one you posted: "genirq: Add IRQF_FORCE_RESUME". You missed the
> changes in include/linux/interrupt.h for the IRQF_MODIFY_MASK.
> 
> Was that intentional?

Yes, because irq.h is missing the IRQ_... flag as well. It's only
settable via: IRQF_... which is a flag for request/setup_irq.

Thanks,

	tglx

 

Re: [patch 0/4] XEN: Interrupt cleanups

[Konrad Rzeszutek Wilk]

> > <scratches his head> The rework was in Xen code not in generic, and
> > the only generic changes that are in there ..  are your code?
> 
> The point is:
> 
> If you play with generic irq code in Xen in some weird way then you
> basically block me to cleanup something in the core code w/o breaking
> Xen. I wanted to move IRQ_SUSPENDED to a different field and
> accidentally noticed that Xen was fiddling with in -next.

Aaaaah. I somehow thought the problems were with code proposed for
2.6.39, but you are referring to: "xen: events: do not unmask event channels
on resume" (6903591f314b8947d0e362bda7715e90eb9df75e) which was added way
back in November (post 2.6.37 time-frame) - and is already in Linus tree.

OK, now that I've that clear in my head (sorry about this confusion):
> 
> So that's what I'm grumpy about. You hack away in Xen and claim it's
> confined to your code, while in reality it is _NOT_.

.. I can quite understand why you are unhappy about this.
> 
> Again, if there is a problem with the generic code then talk to me.

Absolutely. We appreciate you being quite dilligient about other
sub-platforms and sorry for this screwup.

> 
> That's going to be impossible anyway when I'm done with the
> encapsulation.

Any thoughts on how to fix that code Xen code for that issue?

> 
> Thanks,
> 
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

On Tue, 8 Feb 2011, Konrad Rzeszutek Wilk wrote:
> Aaaaah. I somehow thought the problems were with code proposed for
> 2.6.39, but you are referring to: "xen: events: do not unmask event channels
> on resume" (6903591f314b8947d0e362bda7715e90eb9df75e) which was added way
> back in November (post 2.6.37 time-frame) - and is already in Linus tree.

Ah, right. I was looking at 2.6.37 plain + pending irq changes and next :)
 
> > That's going to be impossible anyway when I'm done with the
> > encapsulation.
> 
> Any thoughts on how to fix that code Xen code for that issue?

That's what the patch you pulled and Ian tested is about. It does the
unmask in the core code when that IRQF_FORCE_RESUME flag is set.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:

> This is what I've in the stable/irq.rework [...] Please tell me if I messed up.

I tested v2.6.38-rc4:
+= git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip irq/for-xen
+= git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/irq.rework

and all seems fine.

Thanks,
Ian.

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

B1;2401;0cOn Wed, 9 Feb 2011, Ian Campbell wrote:

> On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:
> 
> > This is what I've in the stable/irq.rework [...] Please tell me if I messed up.
> 
> I tested v2.6.38-rc4:
> += git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip irq/for-xen
> += git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/irq.rework
> 
> and all seems fine.

stable/irq.rework still has the resume hackery inside.

Thanks,

	tglx

Re: [patch 0/4] XEN: Interrupt cleanups

[Thomas Gleixner]

On Wed, 9 Feb 2011, Thomas Gleixner wrote:

> B1;2401;0cOn Wed, 9 Feb 2011, Ian Campbell wrote:
> 
> > On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > > This is what I've in the stable/irq.rework [...] Please tell me if I messed up.
> > 
> > I tested v2.6.38-rc4:
> > += git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip irq/for-xen
> > += git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/irq.rework
> > 
> > and all seems fine.
> 
> stable/irq.rework still has the resume hackery inside.

Also please check whether your stuff compiles and works with the
following patch. x86 should be fine, if not please yell.
You might need to disable drivers/gpio and drivers/mfd

Thanks,

	tglx
---
 arch/x86/Kconfig |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -63,6 +63,7 @@ config X86
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_TEXT_POKE_SMP
 	select HAVE_GENERIC_HARDIRQS
+	select GENERIC_HARDIRQS_NO_DEPRECATED
 	select HAVE_SPARSE_IRQ
 	select GENERIC_IRQ_PROBE
 	select GENERIC_PENDING_IRQ if SMP

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Wed, 2011-02-09 at 09:46 +0000, Thomas Gleixner wrote:
> B1;2401;0cOn Wed, 9 Feb 2011, Ian Campbell wrote:
> 
> > On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > > This is what I've in the stable/irq.rework [...] Please tell me if I messed up.
> > 
> > I tested v2.6.38-rc4:
> > += git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip irq/for-xen
> > += git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/irq.rework
> > 
> > and all seems fine.
> 
> stable/irq.rework still has the resume hackery inside.

ACK, yes I missed that. Konrad -- looks looks you didn't pick up Thomas'
patch 4/4?

I added that one patch to the above set of merges and tested again --
all fine.

Ian.

Re: [patch 0/4] XEN: Interrupt cleanups

[Ian Campbell]

On Wed, 2011-02-09 at 09:48 +0000, Thomas Gleixner wrote:
> On Wed, 9 Feb 2011, Thomas Gleixner wrote:
> 
> > B1;2401;0cOn Wed, 9 Feb 2011, Ian Campbell wrote:
> > 
> > > On Tue, 2011-02-08 at 16:20 +0000, Konrad Rzeszutek Wilk wrote:
> > > 
> > > > This is what I've in the stable/irq.rework [...] Please tell me if I messed up.
> > > 
> > > I tested v2.6.38-rc4:
> > > += git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip irq/for-xen
> > > += git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen stable/irq.rework
> > > 
> > > and all seems fine.
> > 
> > stable/irq.rework still has the resume hackery inside.
> 
> Also please check whether your stuff compiles and works with the
> following patch. x86 should be fine, if not please yell.

Applied on top of the above += your 4/4 patch.

Compiled and tested as dom0 and PV domU -- Works For Me (tm), incl PV
migration.

Thanks,
Ian.