All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.