From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 21 22:11:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FAA4106567C for ; Tue, 21 Jun 2011 22:11:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8E88FC0C for ; Tue, 21 Jun 2011 22:11:47 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5LM5U3x082537 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2011 16:05:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110621204052.GA10649@tops> Date: Tue, 21 Jun 2011 16:05:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com> References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> <4DFACB99.1030707@thebarn.com> <20110621204052.GA10649@tops> To: Gleb Kurtsou X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 21 Jun 2011 16:05:32 -0600 (MDT) Cc: Russell Cattelan , freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 22:11:47 -0000 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=