[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 ...).

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.