From: Gleb Natapov <gleb@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>, Glauber Costa <glommer@gmail.com>
Subject: Re: KVM: x86: limit difference between kvmclock updates
Date: Tue, 14 May 2013 12:05:13 +0300 [thread overview]
Message-ID: <20130514090513.GB20995@redhat.com> (raw)
In-Reply-To: <20130509232141.GA7642@amt.cnet>
On Thu, May 09, 2013 at 08:21:41PM -0300, Marcelo Tosatti wrote:
>
> kvmclock updates which are isolated to a given vcpu, such as vcpu->cpu
> migration, should not allow system_timestamp from the rest of the vcpus
> to remain static. Otherwise ntp frequency correction applies to one
> vcpu's system_timestamp but not the others.
>
> So in those cases, request a kvmclock update for all vcpus. The worst
> case for a remote vcpu to update its kvmclock is then bounded by maximum
> nohz sleep latency.
>
Does this mean that when one vcpu is migrated all others are kicked out
from a guest mode?
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 94f35d2..a37cadc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1569,6 +1569,30 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
> return 0;
> }
>
> +/*
> + * kvmclock updates which are isolated to a given vcpu, such as
> + * vcpu->cpu migration, should not allow system_timestamp from
> + * the rest of the vcpus to remain static. Otherwise ntp frequency
> + * correction applies to one vcpu's system_timestamp but not
> + * the others.
> + *
> + * So in those cases, request a kvmclock update for all vcpus.
> + * The worst case for a remote vcpu to update its kvmclock
> + * is then bounded by maximum nohz sleep latency.
> + */
> +
> +static void kvm_gen_kvmclock_update(struct kvm_vcpu *v)
> +{
> + int i;
> + struct kvm *kvm = v->kvm;
> + struct kvm_vcpu *vcpu;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + set_bit(KVM_REQ_CLOCK_UPDATE, &vcpu->requests);
> + kvm_vcpu_kick(vcpu);
> + }
> +}
> +
> static bool msr_mtrr_valid(unsigned msr)
> {
> switch (msr) {
> @@ -1965,7 +1989,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> kvmclock_reset(vcpu);
>
> vcpu->arch.time = data;
> - kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
> + kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
>
> /* we verify if the enable bit is set... */
> if (!(data & 1))
> @@ -2684,7 +2708,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> * kvmclock on vcpu->cpu migration
> */
> if (!vcpu->kvm->arch.use_master_clock || vcpu->cpu == -1)
> - kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
> + kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
> if (vcpu->cpu != cpu)
> kvm_migrate_timers(vcpu);
> vcpu->cpu = cpu;
> @@ -5704,6 +5728,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> __kvm_migrate_timers(vcpu);
> if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
> kvm_gen_update_masterclock(vcpu->kvm);
> + if (kvm_check_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu))
> + kvm_gen_kvmclock_update(vcpu);
> if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, vcpu)) {
> r = kvm_guest_time_update(vcpu);
> if (unlikely(r))
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 7823b63..044b0b9 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -126,6 +126,7 @@ static inline bool is_error_page(struct page *page)
> #define KVM_REQ_MCLOCK_INPROGRESS 19
> #define KVM_REQ_EPR_EXIT 20
> #define KVM_REQ_SCAN_IOAPIC 21
> +#define KVM_REQ_GLOBAL_CLOCK_UPDATE 22
>
> #define KVM_USERSPACE_IRQ_SOURCE_ID 0
> #define KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID 1
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
next prev parent reply other threads:[~2013-05-14 9:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 23:21 KVM: x86: limit difference between kvmclock updates Marcelo Tosatti
2013-05-14 9:05 ` Gleb Natapov [this message]
2013-05-14 13:12 ` Marcelo Tosatti
2013-05-15 17:41 ` Gleb Natapov
2013-05-15 19:01 ` Marcelo Tosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130514090513.GB20995@redhat.com \
--to=gleb@redhat.com \
--cc=glommer@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.