From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
qemu-devel@nongnu.org, "Stefan Haberland" <sth@linux.ibm.com>,
qemu-s390x@nongnu.org, psundara@redhat.com,
"Jan Höppner" <hoeppner@linux.ibm.com>,
linux-s390@vger.kernel.org
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:09:20 +0100 [thread overview]
Message-ID: <20191216130920.42711f32.cohuck@redhat.com> (raw)
In-Reply-To: <ffea8f68-714b-798e-3563-12f9bf0668fa@de.ibm.com>
On Mon, 16 Dec 2019 12:29:24 +0100
Christian Borntraeger <borntraeger@de.ibm.com> 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?
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390@vger.kernel.org,
"Jan Höppner" <hoeppner@linux.ibm.com>,
"Thomas Huth" <thuth@redhat.com>,
qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
"Stefan Haberland" <sth@linux.ibm.com>,
psundara@redhat.com
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:09:20 +0100 [thread overview]
Message-ID: <20191216130920.42711f32.cohuck@redhat.com> (raw)
In-Reply-To: <ffea8f68-714b-798e-3563-12f9bf0668fa@de.ibm.com>
On Mon, 16 Dec 2019 12:29:24 +0100
Christian Borntraeger <borntraeger@de.ibm.com> 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?
next prev parent reply other threads:[~2019-12-16 12:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 11:24 [RFC QEMU PATCH] pc-bios/s390-ccw: Add zipl-like "BOOT_IMAGE=x" to the kernel parameters Thomas Huth
2019-12-16 11:24 ` Thomas Huth
2019-12-16 11:29 ` Christian Borntraeger
2019-12-16 11:29 ` Christian Borntraeger
2019-12-16 12:09 ` Cornelia Huck [this message]
2019-12-16 12:09 ` Cornelia Huck
2019-12-16 12:15 ` Christian Borntraeger
2019-12-16 12:15 ` Christian Borntraeger
2019-12-16 12:18 ` Thomas Huth
2019-12-16 12:18 ` Thomas Huth
2019-12-16 13:43 ` Peter Oberparleiter
2019-12-16 13:43 ` Peter Oberparleiter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191216130920.42711f32.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=hoeppner@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=psundara@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=sth@linux.ibm.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.