On Tue, 2011-01-04 at 12:45 +0100, Jan Kiszka wrote: > Am 04.01.2011 12:43, Glauber Costa wrote: > > On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote: > >> Am 04.01.2011 12:08, Glauber Costa wrote: > >>> On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote: > >>>> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >>>> > >>>> If kvmclock is used, which implies the kernel supports it, register a > >>>> kvmclock device with the sysbus. Its main purpose is to save and restore > >>>> the kernel state on migration, but this will also allow to visualize it > >>>> one day. > >>> > >>> I would prefer having no pre-save, and doing the ioctl in the state > >>> change handler. But I won't nitpick about that, if the maintainers think > >>> this is okay, all the rest of the patch looks fine as well. > >> > >> I did this for a reason: to be able to obtain the current clock state > >> even while the vm is running. It's cleaner IMHO. > > > > but if we're on pre-save, we are certain that the vm is stopped at this > > moment, no ? > > Maybe at the moment, but not for device state dumping or maybe (dunno) > for Kemari's continuous sync'ing. I simply want to avoid this implicit > dependency. that's fine. -- 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
