> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 08 June 2020 13:47 > To: p...@xen.org > Cc: 'Jürgen Groß' <jgr...@suse.com>; 'Marek Marczykowski-Górecki' > <marma...@invisiblethingslab.com>; > 'Ian Jackson' <ian.jack...@eu.citrix.com>; 'Andrew Cooper' > <andrew.coop...@citrix.com>; 'xen-devel' > <xen-devel@lists.xenproject.org> > Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in > stubdom > > On 08.06.2020 14:38, Paul Durrant wrote: > >> From: Jürgen Groß <jgr...@suse.com> > >> Sent: 08 June 2020 10:25 > >> > >> On 08.06.20 11:15, Paul Durrant wrote: > >>>> From: Jan Beulich <jbeul...@suse.com> > >>>> Sent: 08 June 2020 09:14 > >>>> > >>>> On 05.06.2020 18:18, 'Marek Marczykowski-Górecki' wrote: > >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 > >>>>> (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done > >>>>> (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 > >>>> > >>>> Can either of you tell why this is? As said before, qemu shouldn't > >>>> start tearing down ioreq servers until the domain has made it out > >>>> of all shutdown deferrals, and all its vCPU-s have been paused. > >>>> For the moment I think the proposed changes, while necessary, will > >>>> mask another issue elsewhere. The @releaseDomain xenstore watch, > >>>> being the trigger I would consider relevant here, will trigger > >>>> only once XEN_DOMINF_shutdown is reported set for a domain, which > >>>> gets derived from d->is_shut_down (i.e. not mistakenly > >>>> d->is_shutting_down). > >>> > >>> I can't find anything that actually calls xendevicemodel_shutdown(). It > >>> was added by: > >> > >> destroy_hvm_domain() in qemu does. > >> > > > > Ah ok, thanks. So it looks like this should only normally be called when > > the guest has written to > the PIIX to request shutdown. Presumably the hvm_destroy_ioreq_server call we > see afterwards is QEMU > then exiting. > > If a shutdown request was received, qemu should still not exit as long > as there's in-flight I/O, or as long as there are CPUs running in the > guest. It would seem legitimate to "cancel" in-flight I/O (and perhaps > "reject" further requests arriving), but the device model needs to > remain there as long as there's at least one running CPU. That's no > different on "real" hardware - the machine doesn't "disappear" just > because shutdown was requested.
Yes, I would not expect QEMU to exit straight away... or at all, until killed by the toolstack. So that's the next thing to investigate. Paul > > Jan
