linux-kernel - Re: PCI PM: Restore standard config registers of all devices early

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2009 22:49:31 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jesse.barnes@...el.com>,
	Andreas Schwab <schwab@...e.de>, Len Brown <lenb@...nel.org>
Subject: Re: PCI PM: Restore standard config registers of all devices early

On Monday 02 February 2009, Benjamin Herrenschmidt wrote:
> 
> > I suspect that we could possibly make ACPI happy by actually leaving 
> > interrupts "enabled" in the suspend-late (and early-resume) paths, but 
> > with all hardware interrupts actually turned off. But that's really just a 
> > "let's fool people by turning off interrupts a different way" thing - it 
> > in no way really changes any fundamental issues.
> 
> Well, it might be the right approach ... for the simple reason that ACPI
> doesn't -really- need external interrupts off ... it's a side effect of
> the interpreter using mutexes etc... 
> 
> So maybe indeed we should look into doing something like that, in fact,
> I quite like it:
> 
>  * suspend:
> 
>     - suspend devices with IRQs on
>     - suspend PICs (ie, mask all interrupts). the main kernel clock 
>       source should be kept running tho
>     - do the device suspend "late" thing involving ACPI etc..

I think it would be easier to make ACPI allow us to run AML with interrupts
off.

>  * resume:
> 
>      the other way around.
> 
> Do we still need a real suspend "late" with hard IRQs off in that
> scenario ?
> 
> Granted, because we are still effectively scheduling etc... we might
> have the driver being hit by requests etc... so the suspend_late in the
> above setup loses the property of being shielded against that...

Well, I don't think we'd need it in this case.

> > Whether you use "disable_irq() over all interrupts" or "local_irq_save -> 
> > local_irq_restore" really doesn't change anything. You cannot do this in a 
> > single phase, because that means that you randomly disable interrupts too 
> > early (or enable them too late) when drivers still _require_ them.
> 
> Well, sort-of. IE. local_irq_save() vs. disable_irq() has a relevant
> difference in our context ... the ability to use mutexes, msleep, etc...
> which may allow ACPI to operate.
> 
> I don't care about ACPI on powerpc, so I'm happy hooking the gating with
> irqs off ... but the existing hook isn't in the right place imho.
> 
> > Quite frankly, I don't think the second one is workable. It may be the 
> > optimal one in theory, but it's never worked for us in practice.
> 
> True, it's going to be a pain. However, I still think you're going to
> be bitten somewhere if you whack config space back before you called
> the appropriate ACPI magic to resume the device, but I may be wrong,
> maybe nobody will ever implement really aggressive power management
> in their AML ? :-)

In theory, if the device supports native PCI PM, it should be safe to put it
into D0 using that and restore the config registers.

Still, there may be some strange planar devices that need AML to power them
up.  We'll see. :-)

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