Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts duringsuspend-resume

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

> "Rafael J. Wysocki" <rjw@xxxxxxx> writes:
> 
> > On Sunday 22 February 2009, Rafael J. Wysocki wrote:
> >> On Sunday 22 February 2009, Linus Torvalds wrote:
> >> > 
> >> > On Sun, 22 Feb 2009, Rafael J. Wysocki wrote:
> > [--snip--]
> >> 
> >> Thanks a lot for your comments, I'll send an updated patch shortly.
> >
> > The updated patch is appended.
> >
> > It has been initially tested, but requires more testing, especially with APM,
> > XEN, kexec jump etc.
> >
> > Thanks,
> > Rafael
> >
> > ---
> > From: Rafael J. Wysocki <rjw@xxxxxxx>
> > Subject: PM: Rework handling of interrupts during suspend-resume (rev. 2)
> >
> > Introduce two helper functions allowing us to disable device 
> > interrupts (at the IO-APIC level) during suspend or 
> > hibernation and enable them during the subsequent resume, 
> > respectively, so that the timer interrupts are enabled while 
> > "late" suspend callbacks and "early" resume callbacks 
> > provided by device drivers are being executed.
> >
> > Use these functions to rework the handling of interrupts 
> > during suspend (hibernation) and resume.  Namely, interrupts 
> > will only be disabled on the CPU right before suspending 
> > sysdevs, while device interrupts will be disabled (at the 
> > IO-APIC level), with the help of the new helper function, 
> > before calling "late" suspend callbacks provided by device 
> > drivers and analogously during resume.
> 
> I don't have an issue with the code, but I do have an issue 
> with this description of it.
> 
> Calling disable especially for ioapics does nothing directly. 
> It simply arranges for the irq to be marked pending and for 
> the irq to be masked if the irq happens.
> 
> So what you are doing is arranging so that no interrupts will 
> be delivered to drivers.  Not really disabling interrupts at 
> the IO-APIC level.
> 
> In addition not all interrupts (even on x86) go through an 
> IO-APIC anymore so describing the patch in terms of an IO-APIC 
> makes it a bit hard to understand what your intent actually 
> is.

I think this aspect has been well-understood during the 
discussion of this topic and it's just a slightly misleading 
changelog.

The new suspend code does not rely on truly disabling IRQs on 
the low level. The purpose is to not get IRQs to drivers - which 
might crash/hang/race/misbehave.

Still, it might make sense to not just use the ->disable 
sequence but primarily the ->shutdown irqchip method (when it's 
available in the irqchip).

While we obviously cannot turn off the PIC that delivers timer 
IRQs at this stage - there's no theoretical reason why the 
suspend sequence couldnt power down some secondary PICs as well 
- in some arch code, or maybe even in the generic driver suspend 
sequence if the device tree is structured carefully enough so 
that the PIC gets turned off last.

So turning off all device IRQs in the most lowlevel way possible 
would be prudent. I.e. the suspend stage should do:

                if (desc->chip->shutdown)
                        desc->chip->shutdown(irq);
                else
                        desc->chip->disable(irq);

(there's no change needed for the resume stage)

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