kexec or similar for FreeBSD
gleb.kurtsou at gmail.com
Wed Jun 22 07:53:06 UTC 2011
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.
> >>>> 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.
More information about the freebsd-hackers