Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390

[Alexander Graf]

On 08.05.2012, at 16:43, Christian Borntraeger wrote:

>>> Anthony, this is the prototype of the IPL device that we have talked about 
>>> some weeks
>>> ago. Is an external device to do the IPL process for s390 still ok with you?
>> 
>> Even with an external IPL, we should still be able to detect that a guest 
>> provides 
>> its own virtio-zipl code that contains a boot menu and execute that instead 
>> of directly
>> booting into the first entry, right?
> 
> This is something that we can argue about to find a way to cover all our use 
> cases
> Some of my goals are
> - make it possible to install the boot loader in lpar/vm and boot in kvm and 
> vice versa
> - follow the real HW ipl process (which I do for FCP, but not for dasd/eckd)
> - be able to choose a boot device (-boot <x> is not the right thing for s390)
> - be able to choose an program (loadparm)
> - get a disk booted no matter if FCP, ECKD CDL, ECKD LDL, block size etc as 
> long as this
>  configuration can exist with the current tool sets (that includes ipling 
> disks prepared
>  with the sles11 tools)
> - have some code that can be extended to non-disk boot devices (s390-ipl 
> takes a qdev id
>  as parameter)
> 
> Can you clarify what you need? the code should be modular enough to add a 
> detection, a switch
> or something else to make that possible.

Well, the only shortcomings I'm aware of of the external IPL are:

  * You lose the boot menu. All you get is "entry 0", "entry 1", etc. as the 
description is not part of the boot map
  * You can't choose different entries during runtime. Doing a reboot of a VM 
and selecting a different entry won't work.

The former is pretty annoying if you don't know all of your VMs by heart. The 
latter is an issue when you don't own the qemu process, but do own the VM. 
Think of a hosted environment.

Issue 1 could be fixed for the future by changing the bootmap format to include 
the entry description in a well known format.

As for the runtime selection, we can do some small piece of code that runs 
inside the guest, provides a choice to the user and then issues a call into 
QEMU to IPL into the "real" image. That way QEMU would still read out the 
bootmap and all of the guest RAM is available for the IPL'ed program. We would 
still maintain the ability to interact with the user though.

> Christian 
> 
> PS: long term we probably also want to have real ECKD dasd passthrough as an 
> alternative to 
> virtio for dasds. Then the IPL process will also include interpretation of 
> ipl ccws, but this is 
> something that wont be ready anytime soon

Makes sense. Though it might be useful to be able to run the on-disk code there 
too.


Alex