RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 08 June 2020 13:47
> To: paul@xxxxxxx
> Cc: 'Jürgen Groß' <jgross@xxxxxxxx>; 'Marek Marczykowski-Górecki' 
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx>;
> 'Ian Jackson' <ian.jackson@xxxxxxxxxxxxx>; 'Andrew Cooper' 
> <andrew.cooper3@xxxxxxxxxx>; 'xen-devel'
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> 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ß <jgross@xxxxxxxx>
> >> Sent: 08 June 2020 10:25
> >>
> >> On 08.06.20 11:15, Paul Durrant wrote:
> >>>> From: Jan Beulich <jbeulich@xxxxxxxx>
> >>>> 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