Re: [qemu-s390x] [PATCH v1] s390x: refactor reset/reipl handling

[Christian Borntraeger]

On 06/21/2018 06:07 PM, David Hildenbrand wrote:
> On 21.06.2018 18:04, Cornelia Huck wrote:
>> On Thu, 21 Jun 2018 17:49:56 +0200
>> Christian Borntraeger <address@hidden> 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.

these fast reboots via kexec also work on s390.
But from a machine perspective kexec/kdump is not a reboot. It should not
be blocked by -no-reboot - if it does it would be wrong from a user 
perspective.

> But definitely not for the BIOS :)
> 
>