[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/9] Linux support for vdevice bus
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |