From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDYyT-0003nT-MG for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:50:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDYyN-0005KX-TZ for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:50:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDYyN-0005KM-JH for qemu-devel@nongnu.org; Tue, 11 Oct 2011 05:50:07 -0400 Message-ID: <4E941149.1000208@redhat.com> Date: Tue, 11 Oct 2011 11:50:01 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111010170803.GV9408@redhat.com> <4E933F2D.7090703@codemonkey.ws> <20111011082315.GI14627@redhat.com> <4E940919.7010901@redhat.com> <20111011092728.GL14627@redhat.com> <4E940ED8.9040402@redhat.com> <20111011094900.GM14627@redhat.com> In-Reply-To: <20111011094900.GM14627@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Gleb Natapov , "Richard W.M. Jones" , Alexander Graf , qemu-devel On 10/11/2011 11:49 AM, Daniel P. Berrange wrote: > On Tue, Oct 11, 2011 at 11:39:36AM +0200, Avi Kivity wrote: > > On 10/11/2011 11:27 AM, Daniel P. Berrange wrote: > > >> >For comparison I also did a test building a bootable ISO using ISOLinux. > > >> >This required 700 ms for the boot time, which is appoximately 1/2 the > > >> >time reqiured for direct kernel/initrd boot. But you have to then add > > >> >on time required to build the ISO on every boot, to add custom kernel > > >> >command line args. So while ISO is faster than LinuxBoot currently > > >> >there is still non-negligable overhead here that I want to avoid. > > >> > > >> You can accept parameters from virtio-serial or some other channel. > > >> Is there any reason you need them specifically as *kernel* command > > >> line parameters? > > > > > >Well some of the parameters are actually kernel parameters :-) The rest > > >are things I pass to the 'init' process which runs in the initrd. When > > >this process first starts the only things it can easily access are those > > >builtin to the kernel image, so data available from /proc or /sys like > > >the /proc/cmdline file. It hasn't even loaded things like the virtio-serial > > >or virtio-9pfs kernel modules at this point. > > > > > > > It could, if it wanted to. It's completely custom, yes? > > I'm thinking primarily about debug related parameters, which need to be > used as soon the process starts, not delayed until after we've loaded > kernel modules at which point the step we wanted to debug is already > past. Ah, so there's no issue in regenerating the image if you want to debug. -- error compiling committee.c: too many arguments to function