From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 22 07:53:06 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 17064106577A for ; Wed, 22 Jun 2011 07:53:06 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 95ECD8FC18 for ; Wed, 22 Jun 2011 07:53:05 +0000 (UTC) Received: by fxm11 with SMTP id 11so669708fxm.13 for ; Wed, 22 Jun 2011 00:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0X0G6nDrUJmUPzfddwOx+3qNRmtXK4JPTMluDfkqd7I=; b=MHEYixkHcwyGzpaXQ3qppeyBM54G10hBP0NbVHsKoRFjErw33JElfKF/uOhGf6eDB9 bACqt5nxhGDMxI2K8KKtnQYS2srAWVaj8bhTnBnmD2UXgitcb9VTWxVKmKQdHhoyTTKK FXjGevJ0p4PuUiAB88eRavOj8AwskRBn78p8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=oZwQbTQoFnsTG7wsQEwT1x0rzDGf86EJ4VaztvEaHgeaBZtEK2JFX9BnJPgsAm6Nw1 LZL3pvftzQ/oHWp1byol6j+oY6TAWbE5GgfbfYn5AfKTGkOv+L6K09ea6M4w4TvKk69z Oo6lmLtpVuCiGeW0v0hs/2kyWeQan3Nlnuj2g= Received: by 10.223.75.138 with SMTP id y10mr469454faj.36.1308729184451; Wed, 22 Jun 2011 00:53:04 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id 10sm147203faw.24.2011.06.22.00.53.01 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 00:53:03 -0700 (PDT) Date: Wed, 22 Jun 2011 10:52:53 +0300 From: Gleb Kurtsou To: Warner Losh Message-ID: <20110622075253.GA4187@tops> References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> <4DFACB99.1030707@thebarn.com> <20110621204052.GA10649@tops> <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3055C4CB-5341-4A07-B1E3-F1E7E84575CB@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 22 Jun 2011 07:53:06 -0000 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