Re: [Xen-devel] [patch 5/6] frontend device shutdown

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 21/8/06 3:11 pm, "Gerd Hoffmann" <kraxel@xxxxxxx> wrote:

> But there is another problem on the frontend side:  xenbus_probe_node()
> ignores devices which are not in Initializing state, so it doesn't
> reprobe devices which are about to disappear.  The next kernel should
> probe them, but the frontend state is still Closing (or Closed) ...
> 
> I think that was the initial reason to do the jumpback to Initializing
> (so the new kexec'ed kernel finds an environment identical to the direct
> boot).  That was also the reason to introduce the shutdown_in_progress
> flag, so I have some way to avoid re-initializing of the device by the
> old kernel.

I think the problem here is that the xenbus state machine does not
distinguish who is driving a sequence of state changes. There's no easy way
to determine whether a shutdown is triggered by e.g., backend device hotplug
or frontend driver removal / shutdown.

Moving to state Initialising in the frontend is not a great solution. For
example, what happens if a device is hotplug-removed via xm at the same time
the guest is kexec'ing? Instead of moving to Closed the guest will move to
Initialising and the hotplug request is 'lost' because the new guest kernel
instance will simply reconnect to the still-waiting backend.

I think a better solution is for hotplug events to create a new node in the
backend directory. Something nice and explicit, like 'deleted'. Backend
drivers can choose to device_unregister() only if XenbusStateUnknown or the
node 'deleted' exists. We can check for 'deleted' at the otherend in
xenbus_probe_node() and bail if we see it.

Does this sound plausible?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel