Re: [RFC QEMU PATCH] pc-bios/s390-ccw: Add zipl-like "BOOT_IMAGE=x" to the kernel parameters

[Peter Oberparleiter <oberpar@linux.ibm.com>]

On 16.12.2019 12:29, Christian Borntraeger wrote:
> 
> 
> On 16.12.19 12:24, Thomas Huth wrote:
>>  Note: I've marked the patch as RFC since I'm not quite sure whether
>>  this is really the right way to address this issue: It's unfortunate
>>  that we have to mess with different location in ZIPL which might also
>>  change again in the future.

Having QEMU or any other tooling rely on undocumented on-disk format
specifics of zipl is definitely wrong and prone to break with the next
change. This is _not_ an ABI.

>>  As suggested by Christian on IRC last week,
>>  maybe it would make more sense to change ZIPL to add this parameter
>>  already when zipl is installed (i.e. by the Linux userspace "zipl" pro-
>>  gram), instead of adding it during boot time? Also, the BOOT_IMAGE para-
>>  meter on s390x is quite different from the BOOT_IMAGE paramter that is
>>  used on x86 - while s390x only uses one single number here, the x86
>>  variant (added by grub2, I guess) uses the boot device + full filename
>>  of the kernel on the boot partition. Should we maybe make the s390x
>>  variant more conform to x86? If so, I think this really has to be fixed
>>  in zipl userspace tool, and not in the s390-ccw bios (and zipl stage3
>>  bootloader).
> 
> Yes, I actually think we should revisit the whole BOOT_IMAGE scheme on s390.
> Maybe we should use the kernel name, or the name of the boot menu entry.
> And maybe we should not use 0 (when the default is running) but instead
> really use to what 0 points to.

BOOT_IMAGE on s390 currently only exists for DASD, so any tooling that
relies on it today would be broken for SCSI boot. The equivalent
information for SCSI would be the boot program selector at
/sys/firmware/ipl/bootprog. There is currently no other way to get this
information when booting from DASD.

Also note that the format of BOOT_IMAGE is dependent on the boot loader
that created it. The use of the menu number (and 0 for default) has the
advantage that this number can be used, e.g. to select the same number
for the next boot using the LOADPARM. Changing BOOT_IMAGE to show the
kernel name would take away that use case.

At this time I would suggest to start by identifying any current users
of BOOT_IMAGE and to understand what their actual requirement is. Once
that information is available, we can think about how this requirement
could best be implemented. Looking at the dracut link it seems like
their requirement cannot be met at all with the information currently
provided on s390 via the BOOT_IMAGE parameter.

-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany