Re: [RFC PATCH 3/3] boot bzImages under paravirt

[Rusty Russell <rusty@rustcorp.com.au>]

On Fri, 2007-05-04 at 08:38 -0600, Eric W. Biederman wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> > We can no longer assume the launcher has set the bss to zero: we now
> > need to zero it ourselves.
> 
> Ok.  Although we can hoist the bss zeroing, if everything needs it.

Hi Eric!

	Yeah, Jeremy said he wanted it for Xen.  This is the advantage of
having code in front of us tho.

> Are you booting with P=V now?  If not I expect you will run
> into trouble if you set CONFIG_RELOCATABLE.

	Yep... haven't tried CONFIG_RELOCATABLE tho.  It's kinda exotic 8)

> Hmm.  I'm wondering about the segment reload and how much of a problem
> that is.  My memory says that segment reloads are not actually a
> privileged operation, so we may be able to support this even in
> paravirt mode.  How hard would that be to support?  The segment
> we reload is a fixed part of our boot protocol.

It was a PITA because we can't just load $0x18 into %ss: it has to be
$0x19.  I started doing it (read %cs, mask off bottom 2 bits, orl
__BOOT_DS), but between that extra code and the extra code to then
change segments back...  well, we have to skip the cli anyway so it was
easy to skip them all.

I think Jeremy said Xen doesn't start on the boot descriptors either.  I
have to wonder why we don't just run on the boot descriptors forever
(#define __KERNEL_DS __BOOT_DS etc)?

> I guess this works.  You don't handle the old case of set_sectors == 0
> but I guess you don't support any kernels where that is the case.

Yes, I want to clean that up with proper checks for signatures
(currently, if it's not ELF, it's assumed to be a bzImage).  Might as
well at least error out if there's some surprise.

Thanks for the feedback!
Rusty.
Eric