This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Gerd Hoffmann <kraxel@xxxxxxx>, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 5/6] frontend device shutdown
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 21 Aug 2006 17:11:37 +0100
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 21 Aug 2006 09:11:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44E9BF0D.3090705@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbFPHp3uSOL4zEvEduVWAAKle7CWA==
Thread-topic: [Xen-devel] [patch 5/6] frontend device shutdown
User-agent: Microsoft-Entourage/
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