| Message ID | 1291644227-22923-2-git-send-email-glommer@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote: > Usually nobody usually thinks about that scenario (me included and specially), > but kvmclock can be actually disabled in the host. > > It happens in two scenarios: > 1. host too old. > 2. we passed -kvmclock to our -cpu parameter. > > In both cases, we should not register kvmclock savevm section. This patch > achives that by registering this section only if kvmclock is actually > currently enabled in cpuid. > > The only caveat is that we have to register the savevm section a little bit > later, since we won't know the final kvmclock state before cpuid gets parsed. What is the problem of registering the section? Restoring the value if the host does not support it returns an error? Can't you ignore the error if kvmclock is not reported in cpuid, in the restore handler? Also, please generate against uq/master.
On Mon, Dec 06, 2010 at 07:04:01PM -0200, Marcelo Tosatti wrote: > On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote: > > Usually nobody usually thinks about that scenario (me included and specially), > > but kvmclock can be actually disabled in the host. > > > > It happens in two scenarios: > > 1. host too old. > > 2. we passed -kvmclock to our -cpu parameter. > > > > In both cases, we should not register kvmclock savevm section. This patch > > achives that by registering this section only if kvmclock is actually > > currently enabled in cpuid. > > > > The only caveat is that we have to register the savevm section a little bit > > later, since we won't know the final kvmclock state before cpuid gets parsed. > > What is the problem of registering the section? Restoring the value if > the host does not support it returns an error? > > Can't you ignore the error if kvmclock is not reported in cpuid, in the > restore handler? > > Also, please generate against uq/master. Sorry, this is not upstream yet, so ignore the uq/master part.
On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote: > On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote: > > Usually nobody usually thinks about that scenario (me included and specially), > > but kvmclock can be actually disabled in the host. > > > > It happens in two scenarios: > > 1. host too old. > > 2. we passed -kvmclock to our -cpu parameter. > > > > In both cases, we should not register kvmclock savevm section. This patch > > achives that by registering this section only if kvmclock is actually > > currently enabled in cpuid. > > > > The only caveat is that we have to register the savevm section a little bit > > later, since we won't know the final kvmclock state before cpuid gets parsed. > > What is the problem of registering the section? Restoring the value if > the host does not support it returns an error? > > Can't you ignore the error if kvmclock is not reported in cpuid, in the > restore handler? We can change the restore handler, but not the restore handler of binaries that are already out there. The motivation here is precisely to address migration to hosts without kvmclock, so it's better to have a way to disable, than to count on the fact that the other side will be able to ignore it.
On Tue, Dec 07, 2010 at 03:12:36PM -0200, Glauber Costa wrote: > On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote: > > On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote: > > > Usually nobody usually thinks about that scenario (me included and specially), > > > but kvmclock can be actually disabled in the host. > > > > > > It happens in two scenarios: > > > 1. host too old. > > > 2. we passed -kvmclock to our -cpu parameter. > > > > > > In both cases, we should not register kvmclock savevm section. This patch > > > achives that by registering this section only if kvmclock is actually > > > currently enabled in cpuid. > > > > > > The only caveat is that we have to register the savevm section a little bit > > > later, since we won't know the final kvmclock state before cpuid gets parsed. > > > > What is the problem of registering the section? Restoring the value if > > the host does not support it returns an error? > > > > Can't you ignore the error if kvmclock is not reported in cpuid, in the > > restore handler? > > We can change the restore handler, but not the restore handler of > binaries that are already out there. The motivation here is precisely to > address migration to hosts without kvmclock, so it's better to have > a way to disable, than to count on the fact that the other side will be > able to ignore it. OK. Can't you register conditionally on kvmclock cpuid bit at the end of kvm_arch_init_vcpu, in target-i386/kvm.c?
On Wed, 2010-12-08 at 17:31 -0200, Marcelo Tosatti wrote: > On Tue, Dec 07, 2010 at 03:12:36PM -0200, Glauber Costa wrote: > > On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote: > > > On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote: > > > > Usually nobody usually thinks about that scenario (me included and specially), > > > > but kvmclock can be actually disabled in the host. > > > > > > > > It happens in two scenarios: > > > > 1. host too old. > > > > 2. we passed -kvmclock to our -cpu parameter. > > > > > > > > In both cases, we should not register kvmclock savevm section. This patch > > > > achives that by registering this section only if kvmclock is actually > > > > currently enabled in cpuid. > > > > > > > > The only caveat is that we have to register the savevm section a little bit > > > > later, since we won't know the final kvmclock state before cpuid gets parsed. > > > > > > What is the problem of registering the section? Restoring the value if > > > the host does not support it returns an error? > > > > > > Can't you ignore the error if kvmclock is not reported in cpuid, in the > > > restore handler? > > > > We can change the restore handler, but not the restore handler of > > binaries that are already out there. The motivation here is precisely to > > address migration to hosts without kvmclock, so it's better to have > > a way to disable, than to count on the fact that the other side will be > > able to ignore it. > > OK. Can't you register conditionally on kvmclock cpuid bit at the end of > kvm_arch_init_vcpu, in target-i386/kvm.c? Haven't looked at it, but will today. Actually, tsc has (obviously) the same problem and I plan to respin the patch today including a fix for it as well. Thanks!
diff --git a/cpus.c b/cpus.c index a55c330..a24098e 100644 --- a/cpus.c +++ b/cpus.c @@ -97,6 +97,9 @@ void cpu_synchronize_all_post_init(void) for (cpu = first_cpu; cpu; cpu = cpu->next_cpu) { cpu_synchronize_post_init(cpu); } + if (kvm_enabled()) { + kvmclock_register_savevm(); + } } int cpu_is_stopped(CPUState *env) diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c index 20b7d6d..14a52ce 100644 --- a/qemu-kvm-x86.c +++ b/qemu-kvm-x86.c @@ -504,6 +504,9 @@ static void kvmclock_pre_save(void *opaque) { struct kvm_clock_data *cl = opaque; + if (!kvmclock_enabled) + return; + kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, cl); } @@ -528,6 +531,16 @@ static const VMStateDescription vmstate_kvmclock= { }; #endif +/* This has to happen after vcpu setup*/ +void kvmclock_register_savevm(void) +{ +#ifdef KVM_CAP_ADJUST_CLOCK + if (kvmclock_enabled && kvm_check_extension(kvm_state, KVM_CAP_ADJUST_CLOCK)) { + vmstate_register(NULL, 0, &vmstate_kvmclock, &kvmclock_data); + } +#endif +} + int kvm_arch_qemu_create_context(void) { int r; @@ -545,12 +558,6 @@ int kvm_arch_qemu_create_context(void) return -1; } -#ifdef KVM_CAP_ADJUST_CLOCK - if (kvm_check_extension(kvm_state, KVM_CAP_ADJUST_CLOCK)) { - vmstate_register(NULL, 0, &vmstate_kvmclock, &kvmclock_data); - } -#endif - r = kvm_set_boot_cpu_id(0); if (r < 0 && r != -ENOSYS) { return r; diff --git a/qemu-kvm.h b/qemu-kvm.h index 0f3fb50..0a104ef 100644 --- a/qemu-kvm.h +++ b/qemu-kvm.h @@ -752,6 +752,9 @@ int handle_tpr_access(void *opaque, CPUState *env, uint64_t rip, #define qemu_kvm_cpu_stop(env) do {} while(0) #endif +extern int kvmclock_enabled; +void kvmclock_register_savevm(void); + #ifdef CONFIG_KVM typedef struct KVMSlot { diff --git a/target-i386/kvm.c b/target-i386/kvm.c index 95e5d02..5443765 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -293,6 +293,7 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status, } static int _kvm_arch_init_vcpu(CPUState *env); +int kvmclock_enabled = 1; int kvm_arch_init_vcpu(CPUState *env) { @@ -350,6 +351,12 @@ int kvm_arch_init_vcpu(CPUState *env) memset(c, 0, sizeof(*c)); c->function = KVM_CPUID_FEATURES; c->eax = env->cpuid_kvm_features & get_para_features(env); + + if (!(c->eax & (1 << KVM_FEATURE_CLOCKSOURCE))) { + /* In theory cpuid is per-cpu, and this is a global variable, + * but we don't expect kvmclock enabled in some cpus only */ + kvmclock_enabled = 0; + } #endif cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
Usually nobody usually thinks about that scenario (me included and specially), but kvmclock can be actually disabled in the host. It happens in two scenarios: 1. host too old. 2. we passed -kvmclock to our -cpu parameter. In both cases, we should not register kvmclock savevm section. This patch achives that by registering this section only if kvmclock is actually currently enabled in cpuid. The only caveat is that we have to register the savevm section a little bit later, since we won't know the final kvmclock state before cpuid gets parsed. Signed-off-by: Glauber Costa <glommer@redhat.com> --- cpus.c | 3 +++ qemu-kvm-x86.c | 19 +++++++++++++------ qemu-kvm.h | 3 +++ target-i386/kvm.c | 7 +++++++ 4 files changed, 26 insertions(+), 6 deletions(-)