Re: [PATCH v2 14/17] kvm: x86: Introduce kvmclock device to save/restore its state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/03/2011 06:30 PM, 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.

Okay, thanks for the correction.

--
error compiling committee.c: too many arguments to function

--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux