On 21.06.2018 18:06, Christian Borntraeger wrote: > > > On 06/21/2018 06:04 PM, Cornelia Huck wrote: >> On Thu, 21 Jun 2018 17:49:56 +0200 >> Christian Borntraeger <[email protected]> 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? > > At least thats how it worked until 2.12. Without this we have no > kdump/kexec/ipl > as soon as somebody uses -no-reboot. > Paolo even said that consistent -no-reboot handling would be one of the benefits :)
> > Shall I respin my patch as proper patch? Yes, sure. -- Thanks, David / dhildenb
