Re: kexec or similar for FreeBSD



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
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: maximum hard drive size in Latitude cpi
    ... > actually written a boot loader they won't be so adamant about how "Windows ... > of the disk, and while it is being read off of the disk the machine is ... > limitatoins of that BIOS. ... After that the kernel takes over. ...
    (comp.sys.laptops)
  • Re: Debian bootable on external USB-harddisk
    ... > They are all on the external harddisk since I want to boot from this ... >> fail if you have placed the kernel and initrd on the external ... >> available from BIOS. ... >> grub stage one on the external disk. ...
    (comp.os.linux.setup)
  • FreeBSD Status Report for Oct-Dec 2003
    ... Bluetooth stack for FreeBSD ... Not much to report. ... Bluetooth kernel modules appear to be stable. ... concerns and some src committers are willing to commit the patches. ...
    (freebsd-stable)
  • FreeBSD Status report for Oct-Dec 2003
    ... Bluetooth stack for FreeBSD ... Not much to report. ... Bluetooth kernel modules appear to be stable. ... concerns and some src committers are willing to commit the patches. ...
    (freebsd-current)
  • FreeBSD Status Report for Oct-Dec 2003
    ... Bluetooth stack for FreeBSD ... Not much to report. ... Bluetooth kernel modules appear to be stable. ... concerns and some src committers are willing to commit the patches. ...
    (freebsd-hackers)