[Top][All Lists]

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

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

From: David Hildenbrand
Subject: Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling
Date: Wed, 9 May 2018 16:15:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 24.04.2018 12:18, 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
> 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.
> Let's execute any CPU initialization code on the target CPU using
> run_on_cpu.
> Signed-off-by: David Hildenbrand <address@hidden>
> ---
> RFC -> v1:
> - initital -> initial
> - get rid of goto
> - store CPU index instead of CPU. Fallback to any CPU in case not found
> - handle default case in switch-case

Very friendly ping :)



David / dhildenb

reply via email to

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