qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH for-5.2 0/6] Continue booting in case the first device is not


From: Viktor Mihajlovski
Subject: Re: [PATCH for-5.2 0/6] Continue booting in case the first device is not bootable
Date: Wed, 29 Jul 2020 13:42:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0



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. 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. I however would like to point out that this only covers a corner case (no -boot or -device ..,bootindex specified). A VM defined and started with libvirt will always specify the boot device. Please don't create the impression that this patches will lead to the same behavior as on other platforms. It is still not possible to have an order list of potential boot devices in an architecture compliant way.

[...]

--
Kind Regards,
   Viktor



reply via email to

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