Date: Tue, 21 Jun 2011 16:05:15 -0600 From: Warner Losh <imp@bsdimp.com> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: Russell Cattelan <cattelan@thebarn.com>, freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD Message-ID: <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com> In-Reply-To: <20110621204052.GA10649@tops> References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> <4DFACB99.1030707@thebarn.com> <20110621204052.GA10649@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 21, 2011, at 2:40 PM, Gleb Kurtsou wrote: > On (16/06/2011 22:35), Russell Cattelan wrote: >> On 6/16/11 3:06 PM, Gleb Kurtsou wrote: >>> On (16/06/2011 13:32), Russell Cattelan wrote: >>>> I have been contacted about possibly implementing a fast reboot >>>> mechanism for FreeBSD similar to kexec on Linux. >>>>=20 >>>> I have just started looking into how this accomplished so I figured >>>> a note to freebsd hackers would also be a good place to ask >>>> for comments. >>>>=20 >>>> Has anybody looked at doing something like kexec? >>> I was working on similar project some time ago. First of all you = have to >>> leave hardware in known good state for a new kernel. Reseting = devices >>> can be generally accomplished by unloading corresponding kernel = modules >>> (even if they are compiled in kernel). The biggest problem for me = was >>> timers and programmable interrupt controller. I didn't make it work >>> properly, but my goals where much wider than replacing with another >>> FreeBSD kernel. Aim was to restore initial BIOS state as much as >>> possible. >> What were your goals beyond booting a new kernel? I think getting = back >> to a known BIOS state is kinda required to get a kernel through the = boot >> process. =46rom what I can tell the main goal of kexec is to avoid = the process >> of re-initializing the hardware via BIOS. > Yes it's required to be able load device drivers once again. I had to > get back BIOS USB support, both USB HID devices and USB mass storage > access with int 13h. Which is not documented by BIOS vendors. So > decision was made not to boot full OS, but to extend loader and boot > FreeBSD kernel only if necessary rebooting afterwards. Well, if it is really kexec, wouldn't the kernel be able to use its = drivers to load the stuff, rendering the BIOS state irrelevant? Or were = you kexecing /boot/loader, which would be a lot harder... >>>> Is it the right thing to do for FreeBSD. I'm concerned that the = way >>>> FreeBSD handles early kernel modules (loaded via the boot loader) >>>> vs linux which does everything via initrd is going to be a problem. >>> I find loader code easy work with. You could write dummy filesystem >>> implementation for libstand. So that customized loader will load = both >>> kernel and modules yet while running FreeBSD. Your "reboot" = procedure >>> wouldn't even use any BIOS io interrupts. Linux boot is a real mess >>> imho. >>>=20 >> So it is possible to get back to the loader once the kernel is = booted? >> So the running kernel could load the new kernel / modules and then = jump >> back to the loader to start the boot process. > I meant that you can allocate memory and load new kernel and modules > still while running original FreeBSD kernel, i.e. reuse loader code to > load elf objects, pass boot args to kernel, etc. That would require = very > specific memory layout and proper BIOS memory map (SMAP). Unload all > drivers, disable timers and interrupt controller. Then you can start = new > kernel directly without going to loader, thus avoiding real mode crap, > finding original boot device BIOS number and boot0+boot altogether. Yea, what he said :) > I'm not even sure int 13h will always be functional after device was > claimed by FreeBSD driver. It's not the case for USB, ATA should work, > booting from anything else is likely to be a problem. Yup. Once you're in the kernel, all bets are off on BIOS functions on = amd64 (you can't go back to a state where you can call the BIOS without = resetting the CPU aka rebooting). Many bets are off on i386. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3055C4CB-5341-4A07-B1E3-F1E7E84575CB>