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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch 5/6] frontend device shutdown
From: Gerd Hoffmann <kraxel@xxxxxxx>
Date: Tue, 22 Aug 2006 10:04:33 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Delivery-date: Tue, 22 Aug 2006 01:04:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C10F99C9.1244%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <C10F99C9.1244%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060725)
Keir Fraser wrote:
> I think the problem here is that the xenbus state machine does not
> distinguish who is driving a sequence of state changes. 

One of the problems, yes.

The most tricky one is the handover of the frontend device from one
kernel to the next (same issues will come up for some minios+grub based
bootloader if someone goes creating one ...).

The prerequisites we have are:

  * We _must not_ break old domUs.
  * I'd like to be able to boot old domU kernels via kexec, so the
    post-kexec environment should be identical to what the domain
    builder creates today.

The backward compatibility issue makes it very tricky to add new states,
such as "Disconnecting" for example.  Todays domU kernels expect to find
the frontend device state in Initializing and the backend device state
in Initializing or InitWait.  That are the main reasons I went the route
to switch back to Initializing state in the frontend, and I see no easy
way around that.

The backend responds by cleaning up and preparing for the frontend going
to "Connected" state again, and sets its own state to "InitWait" to
signal that to the frontend.  That is a perfectly fine environment for
the new kernel.  Unfortunaly the old kernel's frontend reacts on that
state change too, which did lead to the introduction of the
shutdown_in_progress flag in xenbus_device to avoid that.

I hope that are all gotchas I ran into (thats the problem with two weeks
vacation between writing code and submitting patches, you forget some of
the tricky details ...).



Gerd Hoffmann <kraxel@xxxxxxx>

Xen-devel mailing list