Date: Wed, 22 Jun 2011 10:52:53 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Russell Cattelan <cattelan@thebarn.com>, freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD Message-ID: <20110622075253.GA4187@tops> In-Reply-To: <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com> References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> <4DFACB99.1030707@thebarn.com> <20110621204052.GA10649@tops> <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (21/06/2011 16:05), Warner Losh wrote: > 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. > >>>> > >>>> 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. > >>>> > >>>> 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. From 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... The project I've mentioned was about implementing a solution similar to kexec-loader, it boots Linux kernel and uses kexec to boot another loader or Linux kernel. Linux kernel execution starts in real mode(!) unlike FreeBSD. The project was very different from FreeBSD-kexec I describe. I'd like to avoid running /boot/loader booting FreeBSD kernel directly and to use full-fledged OS to load new kernel and modules. http://www.solemnwarning.net/kexec-loader/ > > >>>> 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. > >>> > >> 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?20110622075253.GA4187>