On 22/8/06 9:04 am, "Gerd Hoffmann" <kraxel@xxxxxxx> wrote:
> * We _must not_ break old domUs.
Indeed.
> * 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.
Nice to have. I might be inclined to push support for compat into the kexec
layer, though (e.g., fixing up xenstore so that old kernels will be happy),
if doing it in core xenbus code seems distasteful.
> 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.
I don't want to add new XenbusStates. I'm talking about a different,
hotplug, status that is rather different: it indicates the status of the
device from the p.o.v. Of the admin and control tools (basically, 'online'
or 'offline'). This node has quite a different purpose from the existing
state node, which is really a low-level mechanism for sync'ing connection
state machines in frontend/backend drivers.
> 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.
Two options:
1. Always enter Closed state, and then run a cleanup phase in the kexec
code which iterates over xenstore device directories, switching
Closed->Initialising.
2. Enter state Initialising if backend's 'hotplug_status' node indicates
'online'. Gate xenbus_probe_node() on kernel_status <= STATE_RUNNING (the
shutdown code only ever gets run after kernel_status is bumped to one of the
shutdown states, I believe).
I think (1) is architecturally cleaner, but I understand it may be a pain to
implement in the constrained post-shutdown kexec environment. I don't think
(2) is too bad, and is more along the lines of what you have already.
-- Keir
> 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 ...).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home