Re: [Xen-devel] [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code...
On 09.12.19 12:55, Durrant, Paul wrote: -Original Message- From: Jürgen Groß Sent: 09 December 2019 11:34 To: Durrant, Paul ; linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org Cc: Boris Ostrovsky ; Stefano Stabellini Subject: Re: [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code... On 05.12.19 15:01, Paul Durrant wrote: ...and make it static xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV frontends when a guest is rebooted. Indeed the function waits for a conpletion which is only set by a call to xenbus_frontend_closed(). This patch removes the shutdown() method from backends and moves xenbus_dev_shutdown() from xenbus_probe.c into xenbus_probe_frontend.c, renaming it appropriately and making it static. Is this a good move considering driver domains? I don't think it can have ever worked properly for driver domains, and with the rest of the patches a backend should be able go away and return unannounced (as long as the domain id is kept... for which patches need to be upstreamed into Xen). At least I'd expect the commit message addressing the expected behavior with rebooting a driver domain and why this patch isn't making things worse. For a clean reboot I'd expect the toolstack to shut down the protocol before rebooting the driver domain, so the backend shutdown method is moot. And I don't believe re-startable driver domains were something that ever made it into support (because of the non-persistent domid problem). I can add something to the commit comment to that effect if you'd like. Yes, please do so. With this you can add my: Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code...
> -Original Message- > From: Jürgen Groß > Sent: 09 December 2019 11:34 > To: Durrant, Paul ; linux-ker...@vger.kernel.org; > xen-devel@lists.xenproject.org > Cc: Boris Ostrovsky ; Stefano Stabellini > > Subject: Re: [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend > code... > > On 05.12.19 15:01, Paul Durrant wrote: > > ...and make it static > > > > xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of > PV > > frontends when a guest is rebooted. Indeed the function waits for a > > conpletion which is only set by a call to xenbus_frontend_closed(). > > > > This patch removes the shutdown() method from backends and moves > > xenbus_dev_shutdown() from xenbus_probe.c into xenbus_probe_frontend.c, > > renaming it appropriately and making it static. > > Is this a good move considering driver domains? I don't think it can have ever worked properly for driver domains, and with the rest of the patches a backend should be able go away and return unannounced (as long as the domain id is kept... for which patches need to be upstreamed into Xen). > > At least I'd expect the commit message addressing the expected behavior > with rebooting a driver domain and why this patch isn't making things > worse. > For a clean reboot I'd expect the toolstack to shut down the protocol before rebooting the driver domain, so the backend shutdown method is moot. And I don't believe re-startable driver domains were something that ever made it into support (because of the non-persistent domid problem). I can add something to the commit comment to that effect if you'd like. Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code...
On 05.12.19 15:01, Paul Durrant wrote: ...and make it static xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV frontends when a guest is rebooted. Indeed the function waits for a conpletion which is only set by a call to xenbus_frontend_closed(). This patch removes the shutdown() method from backends and moves xenbus_dev_shutdown() from xenbus_probe.c into xenbus_probe_frontend.c, renaming it appropriately and making it static. Is this a good move considering driver domains? At least I'd expect the commit message addressing the expected behavior with rebooting a driver domain and why this patch isn't making things worse. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel