On Mon, 2011-01-03 at 17:30 +0100, Jan Kiszka wrote: > Am 03.01.2011 17:04, Avi Kivity wrote: > > On 01/03/2011 10:33 AM, 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. > >> > > > > kvmclock is a per-cpu affair. > > Nope, it's state (the one save/restored here) is per VM. > > > > >> > >> @@ -534,6 +599,10 @@ int kvm_arch_init(int smp_cpus) > >> int ret; > >> struct utsname utsname; > >> > >> +#ifdef KVM_CAP_ADJUST_CLOCK > >> + sysbus_register_withprop(&kvmclock_info); > >> +#endif > >> + > > > > So this doesn't look right. I think we're fine with just migrating the > > MSRs, like we migrate anything else that has to do with the cpu. > > > > The kvmclock state is not contained in any MSR. It's an independent > machine state that can be indirectly obtained via MSR access. Therefore, > qemu-kvm currently registers only one vmstate entry per machine, and > this patch just turns this into a clean device - because that's what > kvmclock is in the end, something like an HPET. Jan is right, the per-cpu information only cares about which piece of memory will be written to. -- 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
