WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Mon, 21 Aug 2006 16:11:25 +0200
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 21 Aug 2006 07:11:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C10CC1B1.81E%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: <C10CC1B1.81E%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.5 (X11/20060725)
> I really don't like that distinction very much (moving to Initialising
> instead of Closed). The problem is really in the backend, which incorrectly
> interprets XenbusStateClosed as a request to completely unregister the
> device. The reason it does this is because the control tools signal that
> destruction should take place by deleting the frontend directory in
> xenstore. This results in xenbus_read_driver_state() returning
> XenbusStateClosed, hence the backend drivers have interpreted that state
> value as a destruction request from the tools.

Ok, that should work fine for the backend side.

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.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@xxxxxxx>
http://www.suse.de/~kraxel/julika-dora.jpeg

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