qemu-s390x
[Top][All Lists]
Advanced

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

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


From: Cornelia Huck
Subject: Re: [qemu-s390x] [PATCH v1] s390x: refactor reset/reipl handling
Date: Wed, 9 May 2018 16:36:07 +0200

On Wed, 9 May 2018 16:15:38 +0200
David Hildenbrand <address@hidden> wrote:

> 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 :)

I'm currently inclined to just go ahead and merge it -- so if anyone
still wants to provide review, now's the time :)



reply via email to

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