[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
> 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.
>
> 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 :)
--
Thanks,
David / dhildenb
- Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling,
David Hildenbrand <=