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

2018-04-24 Thread Christian Borntraeger
Not a full test, but reboot and kdump seem to work ok with KVM. On 04/12/2018 09:26 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

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

2018-04-23 Thread David Hildenbrand
On 23.04.2018 12:42, Cornelia Huck wrote: > On Thu, 12 Apr 2018 21:26:02 +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

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

2018-04-23 Thread David Hildenbrand
On 23.04.2018 12:45, Cornelia Huck wrote: > On Wed, 18 Apr 2018 16:33:13 +0200 > David Hildenbrand wrote: > >>> static void s390_ipl_class_init(ObjectClass *klass, void *data) >>> diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h >>> index 0570d0ad75..102f1ea7af 100644 >>> ---

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

2018-04-23 Thread Cornelia Huck
On Wed, 18 Apr 2018 16:33:13 +0200 David Hildenbrand wrote: > > static void s390_ipl_class_init(ObjectClass *klass, void *data) > > diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h > > index 0570d0ad75..102f1ea7af 100644 > > --- a/hw/s390x/ipl.h > > +++ b/hw/s390x/ipl.h > > @@

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

2018-04-23 Thread Cornelia Huck
On Thu, 12 Apr 2018 21:26:02 +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,

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

2018-04-18 Thread David Hildenbrand
> static void s390_ipl_class_init(ObjectClass *klass, void *data) > diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h > index 0570d0ad75..102f1ea7af 100644 > --- a/hw/s390x/ipl.h > +++ b/hw/s390x/ipl.h > @@ -87,7 +87,17 @@ int s390_ipl_set_loadparm(uint8_t *loadparm); > void

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

2018-04-18 Thread David Hildenbrand
On 18.04.2018 16:08, Thomas Huth wrote: > On 12.04.2018 21:26, 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

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

2018-04-18 Thread Thomas Huth
On 12.04.2018 21:26, 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 RFC] s390x: refactor reset/reipl handling

2018-04-12 Thread Paolo Bonzini
On 12/04/2018 21:26, 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

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

2018-04-12 Thread David Hildenbrand
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