| 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
| ||
|
Message-ID: <m1sl7te714.fsf@ebiederm.dsl.xmission.com> Date: Thu, 12 Jul 2007 13:49:59 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: david@...g.hm Cc: "Huang, Ying" <ying.huang@...el.com>, 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, Kexec Mailing List <kexec@...ts.infradead.org> Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation david@...g.hm writes: > On Thu, 12 Jul 2007, Eric W. Biederman wrote: > >>> 2. Do not reserve memory for kexec kernel. That is, backup needed memory >>> before kexec and restore them after kexec. >>> 3. Support the in-place kexec? The relocatable kernel is not necessary >>> if this can be implemented. >> >> It sounds like what you really want is the normal kexec path enhanced >> so that you can return to the kernel you started with. >> >> The normal kexec path already knows how to do the memory shuffle so >> it can do on demand memory allocation. That code just needs to >> enhanced slightly so that you allocate an extra page, setup an inverse >> scatter gather list for restoring the pages, and teach relocate_kernel.S >> to preserve it's destination pages by using the inverse scatter gather >> list. >> >> The normal kexec path already calls device_shutdown and the like to >> stop devices from running. Although again that code path is not >> prepared to restore the devices. > > we shouldn't need a restore code path if the new kernel re-detects > everything. if kexec already shuts down all the devices we may not need to > implement anything new here (although there may be room for future performance > optimization) Yes, reusing device hotplug... You still need the code path for little things and to kick of the device redetection but if you get lucky it won't have to do much. Of course speed is important. >> ... >> >> For prototyping I would: >> - reserve a chunk of memory (possibly with the crashkernel= option) >> and run a relocatable kernel out of it. >> >> By using the normal kexec you can boot a relocatable restore kernel >> in that reserved region. It is an extra step but it makes things >> work today. >> >> - I would use the normal sys_kexec_load. >> >> - I would debug/tweak the user space and the code to reenter the >> old kernel. I.e. the device driver stop/start code. >> >> Once it was basically working I would the update normal kexec >> memory copy code in relocate.S to preserve the destination pages. > > for prototyping there's no need to use the same kernel. > >>> 4. Image writing/reading. (Only user space application is needed). >> >> And possibly a few fixes to /dev/mem. This is pretty much the same >> process as generating a core dump so there should be some synergy with that. > > what fixes are you thinking of? Don't really know. I figured /dev/mem was sufficient but the kexec on panic folks tell me it doesn't work for areas we have told the kernel isn't memory, I haven't had time so I haven't pushed it. > you are makeing this sound very simple ;-) Which is the primary point of using kexec. If it isn't simple then we are doing something wrong... Eric - 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/
Powered by blists - more mailing lists