qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Borntraeger
Subject: Re: [RFC QEMU PATCH] pc-bios/s390-ccw: Add zipl-like "BOOT_IMAGE=x" to the kernel parameters
Date: Mon, 16 Dec 2019 13:15:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0


On 16.12.19 13:09, Cornelia Huck wrote:
> On Mon, 16 Dec 2019 12:29:24 +0100
> Christian Borntraeger <address@hidden> 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. 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.
> 
> Probably dumb question: Is booting via the s390-ccw bios the only time
> we boot without going through zipl? What about e.g. booting from the
> reader under z/VM? There's probably no BOOT_IMAGE= statement there,
> either?

I just learned from Peter that booting SCSI also has no BOOT_IMAGE (as
we have no menu). So Thomas, can you find out the use case for the initial
bug report.  That might give an indication on how to proceed for all cases.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]