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

2018-06-21 Thread Paolo Bonzini
On 21/06/2018 18:08, David Hildenbrand wrote: >> 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 :) > kdump/kexec (and of course "ipl") do not reboot on x86, so fixing the bug d

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

2018-06-21 Thread Christian Borntraeger
On 06/21/2018 06:15 PM, David Hildenbrand wrote: > On 21.06.2018 17:49, Christian Borntraeger 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 drop

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

2018-06-21 Thread David Hildenbrand
On 21.06.2018 17:49, Christian Borntraeger 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_vcpu

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

2018-06-21 Thread David Hildenbrand
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 wrote: >> >>> On 04/24/2018 12:18 PM, David Hildenbrand wrote: Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread

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

2018-06-21 Thread 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 wrote: >> >>> On 04/24/2018 12:18 PM, David Hildenbrand wrote: Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might >

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

2018-06-21 Thread David Hildenbrand
On 21.06.2018 18:04, Cornelia Huck wrote: > On Thu, 21 Jun 2018 17:49:56 +0200 > Christian Borntraeger 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

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

2018-06-21 Thread David Hildenbrand
On 21.06.2018 17:49, Christian Borntraeger 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_vcpu

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

2018-06-21 Thread Christian Borntraeger
On 06/21/2018 06:04 PM, Cornelia Huck wrote: > On Thu, 21 Jun 2018 17:49:56 +0200 > Christian Borntraeger 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() tempor

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

2018-06-21 Thread Cornelia Huck
On Thu, 21 Jun 2018 17:49:56 +0200 Christian Borntraeger 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 p

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

2018-06-21 Thread Christian Borntraeger
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. (e

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

2018-05-14 Thread Cornelia Huck
On Tue, 24 Apr 2018 12:18:59 +0200 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 de

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

2018-05-09 Thread Cornelia Huck
On Wed, 9 May 2018 16:15:38 +0200 David Hildenbrand 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

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

2018-05-09 Thread David Hildenbrand
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

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

2018-04-26 Thread Cornelia Huck
On Tue, 24 Apr 2018 12:18:59 +0200 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 de