Re: [Qemu-devel] [PATCH 12/13] Add zipl bootloader interpreter

[Alexander Graf]

On 25.11.2009, at 09:35, Hannes Reinecke wrote:

> On Tue, Nov 24, 2009 at 03:10:24PM -0600, Anthony Liguori wrote:
>> Hi Mark!
>> 
>> Mark Williamson wrote:
>>> Way back in the mists of time (uh, something like that 2004-05) I had some 
>>> discussions with some of the S390 people about using kboot for more 
>>> flexible boot, since it tallied with their interests.  Although at that 
>>> point I had the impression that zipl was restricted to only one boot 
>>> option anyhow, so if it can now choose from a list then maybe they just 
>>> enhanced what they had.
>>> 
>>> Anthony, you might remember these discussions?  I don't know if they went 
>>> anywhere with it.
>>> 
>> 
>> I do, that's why I brought it up.  AFAICT, there hasn't been a lot of 
>> progress with kboot.  Carsten or Alex would probably know better if anyone 
>> is actually using it on s390s.
>> 
> No, not to my knowledge.
> 
> There have been some discussion as if kboot would be beneficial here, but
> especially for s390 it doesn't make a lot of sense.

Thanks for clarifying this!

> kboot is okay for scenarios where you have a _lot_ of modules in the default
> kernel, but need only a very small subset to get the system bootstrapped.
> Then you can built a kboot kernel with the driver subset for bootstrapping
> and have that loading the 'normal' kernel which then loads all remaining
> modules.
> 
> If you have (like s390) only about 8 driver modules to care about it's
> pretty much pointless as the kboot kernel will have the same configuration
> than the normal kernel. So you'll end up with loading the same kernel twice.
> 
> And won't change the situation here, as you still have to do the initial
> bootstrap somehow. And as this should be quite close to the original system
> you'll end up having to support zipl anyway.

Yes, you'd basically end up writing a zipl interpreter inside the initrd of 
kboot. Bleks.

> So back to the zipl question, it might be an idea to support initially
> the SCSI disk layout only. This has the advantage of being far simpler
> as the DASD disk layout and should be pretty straightforward to handle.

That's exactly what my zipl patch does. DASD has 4k sector sizes, so DASD 
layouts are not supported. Fortunately virtio in qemu only exports 512 bytes 
sector sizes for now, so when you install the VM onto virtio, you're good.

Alex