Re: [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code...

From: JÃrgen GroÃ
Date: Mon Dec 09 2019 - 06:57:46 EST


On 09.12.19 12:55, Durrant, Paul wrote:
-----Original Message-----
From: JÃrgen Groà <jgross@xxxxxxxx>
Sent: 09 December 2019 11:34
To: Durrant, Paul <pdurrant@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
xen-devel@xxxxxxxxxxxxxxxxxxxx
Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>; Stefano Stabellini
<sstabellini@xxxxxxxxxx>
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 <jgross@xxxxxxxx>


Juergen