linux-kernel - Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

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]

Message-Id: <1184260174.9346.85.camel@caritas-dev.intel.com>
Date:	Thu, 12 Jul 2007 17:09:34 +0000
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base
	hibernation

On Wed, 2007-07-11 at 22:48 -0700, Jeremy Fitzhardinge wrote:
> >> The kexec jump is implemented in the framework of software suspend. In
> >> fact, the kexec based hibernation can be seen as just implementing the
> >> image writing and reading method of software suspend with a kexeced
> >> Linux kernel.
> >>     
> 
> I guess I'm (still) confused by the terminology here.  Do you mean that 
> it fits into suspend-to-disk as a disk-writing mechanism, or in 
> suspend-to-ram as a way of going to sleep?

It fits into suspend-to-disk as a disk-writing mechanism. But most
tricks of suspend-to-disk will be no longer necessary in kexec based
hibernation.

> > I didn't understand the ACPI problem.  Does this mean that CONFIG_ACPI must
> > be disabled in the to-be-hibernated kernel, or in the little transient
> > kexec kernel?
> >   
> 
> I think the point is that if kernel A says "I'm suspending" and calls 
> the suspend method on all its devices, then kernel B finds that it has 
> no powered on devices to work with.  But then couldn't it turn on the 
> ones it wants anyway?  And don't you want to suspend them, to make sure 
> they're not still DMAing memory while B is trying to shuffle everything 
> off to disk?

The devices should be put quiescent state to stop DMA like things. But
they do not need to be put in low power state.

"Do not put devices into low power state" vs. "power on devices during
boot-up"

Which one is easier?

Best Regards,
Huang Ying
-
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/