On Wed, 2006-06-07 at 12:03 +0200, Jacob Gorm Hansen wrote:
> On 6/6/06, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > Subject: Linux support for vdevice bus
> >
> > This patch provides the Linux implementation of the vdevice bus.
> >
> > FIXME: currently it does not support save/restore of the domain: it
> > should call stop before shutting down, and remap shares afterwards
> > before calling reconnect. This depends on exactly what we do with
> > shared pages on restore.
>
> In general I find the 'remember to suspend on save' approach that we
> are currently using for xenbus and drivers problematic, and I much
> favor a 'reset on resume' approach instead. Sometimes when doing a
> save (or migration, or, in my case, self-migration), the domain wants
> to continue running after the save, and then having to shut down all
> external devices just to immediately resume them is inelegant and
> often creates a lot of trouble. If we are to change the IPC/sharing
> mechanism (and you make some good arguments for that), I think we
> should design for 'reset on resume' rather than 'suspend-on-save'.
Thanks for this input Jacob!
Things are simpler enough that this might not be an issue, but...
Let's look at the shared network device as an example. It maps the
share_ref it's told to in the vdevice page, and is reading and writing
to that mapped page (although not in an interrupt, unlike the block
driver).
On restore, the previously mapped pages will no longer be valid, and the
new share_ref needs to be mapped. Even if we remap the new share_refs
in place on restore before allowing interrupts, the driver might process
an interrupt before being told it has to reset, and get confused.
So if we really want all the action to happen on restore, I think we
need a stop!() function for drivers called before interrupts are
re-enabled, and then we can call restart() later at our leisure.
The driver, other than ensuring that "stop" can be called with
interrupts off, doesn't have to know whether it's called during save or
restore.
Seem reasonable?
Rusty.
--
ccontrol: http://ccontrol.ozlabs.org
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home