On Mon, 2010-11-08 at 13:40 +0200, Michael S. Tsirkin wrote: > On Wed, Oct 06, 2010 at 02:58:57PM -0600, Alex Williamson wrote: > > Our code paths for saving or migrating a VM are full of functions that > > return void, leaving no opportunity for a device to cancel a migration, > > either from error or incompatibility. The ivshmem driver attempted to > > solve this with a no_migrate flag on the save state entry. I think the > > more generic and flexible way to solve this is to allow driver save > > functions to fail. This series implements that and converts ivshmem > > to uses a set_params function to NAK migration much earlier in the > > processes. This touches a lot of files, but bulk of those changes are > > simply s/void/int/ and tacking a "return 0" to the end of functions. > > Thanks, > > > > Alex > > Well error handling is always tricky: it seems easier to > require save handlers to never fail. Sure it's easier, but does that make it robust? > So there's a bunch of code here but what exactly is the benefit? > Since save handlers have no idea what does the remote do, > what is the compatibility you mention? There are two users I currently have in mind. ivshmem currently makes use of the register_device_unmigratable() because it makes use of host specific resources and connections (aiui). This sets the no_migrate flag, which is not dynamic and a bit of a band-aide. The other is device assignment, which needs a way to NAK a migration since physical devices are never migratable. I imagine we could at some point have devices with state tied to other features that can't always be detached from the host, this tries to provide the infrastructure for that to happen. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
