From: Thomas Huth <thuth@redhat.com>
To: Viktor Mihajlovski <mihajlov@linux.ibm.com>, qemu-devel@nongnu.org
Cc: qemu-s390x <qemu-s390x@nongnu.org>
Subject: Re: [PATCH for-5.2 0/6] Continue booting in case the first device is not bootable
Date: Thu, 30 Jul 2020 06:39:05 +0200 [thread overview]
Message-ID: <d0b44e40-f800-8471-1a3e-c3ba1eca61a7@redhat.com> (raw)
In-Reply-To: <5c860673-9c0c-79fe-2804-4864856257f5@linux.ibm.com>
On 29/07/2020 13.42, Viktor Mihajlovski wrote:
>
>
> On 7/28/20 8:37 PM, Thomas Huth wrote:
>> If the user did not specify a "bootindex" property, the s390-ccw bios
>> tries to find a bootable device on its own. Unfortunately, it alwasy
>> stops at the very first device that it can find, no matter whether it's
>> bootable or not. That causes some weird behavior, for example while
>>
>> qemu-system-s390x -hda bootable.qcow2
>>
>> boots perfectly fine, the bios refuses to work if you just specify
>> a virtio-scsi controller in front of it:
>>
>> qemu-system-s390x -device virtio-scsi -hda bootable.qcow2
>>
>> Since this is quite uncomfortable and confusing for the users, and
>> all major firmwares on other architectures correctly boot in such
>> cases, too, let's also try to teach the s390-ccw bios how to boot
>> in such cases.
>>
>> For this, we have to get rid of the various panic()s and IPL_assert()
>> statements at the "low-level" function and let the main code handle
>> the decision instead whether a boot from a device should fail or not,
>> so that the main code can continue searching in case it wants to.
>>
>
> Looking at it from an architectural perspective: If an IPL Information
> Block specifying the boot device has been set and can be retrieved using
> Diagnose 308 it has to be respected, even if the device doesn't contain
> a bootable program. The boot has to fail in this case.
>
> I had not the bandwidth to follow all code paths, but I gather that this
> is still the case with the series.
Right. Just to be sure, I just double-checked with:
... -device virtio-blk,drive=baddrive,bootindex=1 \
-device virtio-blk,drive=gooddrive
and indeed, the s390-ccw bios only checks the "baddrive" here and
refuses to boot.
> So one can argue that these changes
> are taking care of an undefined situation (real hardware will always
> have the IPIB set).
>
> As long as the architecture is not violated, I can live with the
> proposed changes.
Thanks!
> I however would like to point out that this only
> covers a corner case (no -boot or -device ..,bootindex specified).
Sure. We™ should/could maybe also add some more documentation to
https://www.qemu.org/docs/master/system/target-s390x.html
to make it more clear to the "unexperienced" qemu-system-s390x users
that "bootindex" is the preferred / architected way of booting there.
> Please don't create the impression that this patches will lead to the
> same behavior as on other platforms.
Ok, I'll try to state that more clearly in the cover letter of v2.
Thomas
next prev parent reply other threads:[~2020-07-30 4:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 18:37 [PATCH for-5.2 0/6] Continue booting in case the first device is not bootable Thomas Huth
2020-07-28 18:37 ` [PATCH for-5.2 1/6] pc-bios/s390-ccw/Makefile: Compile with -std=gnu99, -fwrapv and -fno-common Thomas Huth
2020-07-29 8:00 ` Claudio Imbrenda
2020-07-29 8:34 ` Cornelia Huck
2020-07-31 7:46 ` Janosch Frank
2020-07-31 7:51 ` Thomas Huth
2020-07-28 18:37 ` [PATCH for-5.2 2/6] pc-bios/s390-ccw: Move ipl-related code from main() into a separate function Thomas Huth
2020-07-29 8:01 ` Claudio Imbrenda
2020-07-29 8:47 ` Cornelia Huck
2020-07-29 11:05 ` Thomas Huth
2020-08-05 9:16 ` Cornelia Huck
2020-08-04 12:52 ` Janosch Frank
2020-07-28 18:37 ` [PATCH for-5.2 3/6] pc-bios/s390-ccw: Move the inner logic of find_subch() to " Thomas Huth
2020-07-29 8:54 ` Cornelia Huck
2020-07-29 11:13 ` Thomas Huth
2020-08-05 9:19 ` Cornelia Huck
2020-08-03 8:46 ` Claudio Imbrenda
2020-08-04 13:24 ` Thomas Huth
2020-08-04 15:30 ` Claudio Imbrenda
2020-08-04 13:26 ` Janosch Frank
2020-07-28 18:37 ` [PATCH for-5.2 4/6] pc-bios/s390-ccw: Do not bail out early if not finding a SCSI disk Thomas Huth
2020-07-29 10:03 ` Cornelia Huck
2020-07-28 18:37 ` [PATCH for-5.2 5/6] pc-bios/s390-ccw: Scan through all boot devices if none has been specified Thomas Huth
2020-08-04 11:06 ` Claudio Imbrenda
2020-08-05 9:36 ` Cornelia Huck
2020-08-05 9:39 ` Thomas Huth
2020-07-28 18:37 ` [PATCH for-5.2 6/6] pc-bios/s390-ccw: Allow booting in case the first virtio-blk disk is bad Thomas Huth
2020-08-05 10:04 ` Cornelia Huck
2020-08-05 10:08 ` Thomas Huth
2020-08-05 10:27 ` Cornelia Huck
2020-07-29 10:10 ` [PATCH for-5.2 0/6] Continue booting in case the first device is not bootable Cornelia Huck
2020-07-29 11:42 ` Viktor Mihajlovski
2020-07-29 17:17 ` Cornelia Huck
2020-07-30 4:39 ` Thomas Huth [this message]
2020-08-04 14:49 ` Janosch Frank
2020-08-04 15:19 ` Thomas Huth
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=d0b44e40-f800-8471-1a3e-c3ba1eca61a7@redhat.com \
--to=thuth@redhat.com \
--cc=mihajlov@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).