On 21.06.2018 18:04, Cornelia Huck wrote: > On Thu, 21 Jun 2018 17:49:56 +0200 > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > >> On 04/24/2018 12:18 PM, David Hildenbrand wrote: >>> Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might >>> not be the best idea. As pause_all_vcpus() temporarily drops the qemu >>> mutex, two parallel calls to pause_all_vcpus() can be active at a time, >>> resulting in a deadlock. (either by two VCPUs or by the main thread and a >>> VCPU) >>> >>> Let's handle it via the main loop instead, as suggested by Paolo. If we >>> would have two parallel reset requests by two different VCPUs at the >>> same time, the last one would win. >>> >>> We use the existing ipl device to handle it. The nice side effect is >>> that we can get rid of reipl_requested. >>> >>> This change implies that all reset handling now goes via the common >>> path, so "no-reboot" handling is now active for all kinds of reboots. >> >> Ok, this breaks the s390 IPL process when -no-reboot is specified. >> The bios does a diagnose 308 subcode 1 to jump to the final image while >> at the same time resetting all devices. This is now blocked with -no-reboot >> (although it is actually the boot) >> >> >> I have noticed that with virt-install on iso images since virt-install >> specifies -no-reboot. >> >> Something like this seems to help but it is not a nice solution. > > It's a bit ugly, but allows us to accommodate the different semantics > for the different diag subcodes... the -no-reboot parameter is only > supposed to suppress normal guest reboot requests, right?
The question is if -no-reboot should also be considered for kexec. There are (at least on x86, not sure about s390x) "fast reboot techniques using kexec". So it feels like -no-reboot should also apply for kexec. But definitely not for the BIOS :) -- Thanks, David / dhildenb
