From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Re: pv_ops dom0 USB fixed Date: Wed, 17 Dec 2008 21:33:47 +0000 Message-ID: <1229549628.4802.30.camel@localhost.localdomain> References: <49490F73.6020606@redhat.com> <49495261.8090703@goop.org> <1229547457.4802.16.camel@localhost.localdomain> <49496ECD.6000503@goop.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49496ECD.6000503@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: deshantm@gmail.com, Xen-devel , Aviv Grafi , Gerd Hoffmann , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Wed, 2008-12-17 at 13:27 -0800, Jeremy Fitzhardinge wrote: > Ian Campbell wrote: > > On Wed, 2008-12-17 at 11:26 -0800, Jeremy Fitzhardinge wrote: > > > >>> Also noticed the dom0 builder doesn't (yet) boot bzImages, right? > >>> > >>> > >> Yeah. It's on the todo list, but I don't think anyone's lined up to > >> do it yet. Shouldn't be more than a couple of hours work for someone > >> with some expertise in the area (hint hint). > >> > > > > The main stumbling block is the lack of any existing decompression code > > in the hypervisor. I've got half a patch somewhere which uses Linux's > > inflate.c (it should be in an init section so it's thrown away after > > boot) but it's not complete, it was a while ago so I don't even recall > > how not-complete it was. I can dig it out if someone wants to pick it up > > before I get back round to it. > > > > Ah, right, it was relying on grub to do all the decompression? Yep. > > An alternative option might be a multiboot shim which picks apart any > > bzImage format modules in its input and passes the result down the chain > > to the next module. e.g. your grub entry might look like: > > title bz-xen > > kernel unbzimage > > module xen.gz dom0_mem=foo > > module vmlinuz root=blah > > module initrd > > > > That might be useful to have, but I don't think it would be easier to > implement. Right, which is why I started down the other route ;-) Ian.