linux-kernel - Re: [PATCH 03/18] TSC reset compensation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C431113.10101@redhat.com>
Date:	Sun, 18 Jul 2010 17:34:59 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Zachary Amsden <zamsden@...hat.com>
CC:	KVM <kvm@...r.kernel.org>, Marcelo Tosatti <mtosatti@...hat.com>,
	Glauber Costa <glommer@...hat.com>,
	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/18] TSC reset compensation

On 07/13/2010 05:25 AM, Zachary Amsden wrote:
> Attempt to synchronize TSCs which are reset to the same value.  In the
> case of a reliable hardware TSC, we can just re-use the same offset, but
> on non-reliable hardware, we can get closer by adjusting the offset to
> match the elapsed time.
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 3b4efe2..4b42893 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -396,6 +396,9 @@ struct kvm_arch {
>   	unsigned long irq_sources_bitmap;
>   	s64 kvmclock_offset;
>   	spinlock_t tsc_write_lock;
> +	u64 last_tsc_nsec;
> +	u64 last_tsc_offset;
> +	u64 last_tsc_write;
>    

So that we know what the lock protects, let's have

    struct kvm_global_tsc {
          spinlock_t lock;
          ...
     } tsc;

> @@ -896,10 +896,39 @@ static DEFINE_PER_CPU(unsigned long, cpu_tsc_khz);
>   void guest_write_tsc(struct kvm_vcpu *vcpu, u64 data)
>   {
>   	struct kvm *kvm = vcpu->kvm;
> -	u64 offset;
> +	u64 offset, ns, elapsed;
> +	struct timespec ts;
>
>   	spin_lock(&kvm->arch.tsc_write_lock);
>   	offset = data - native_read_tsc();
> +	ktime_get_ts(&ts);
> +	monotonic_to_bootbased(&ts);
> +	ns = timespec_to_ns(&ts);
> +	elapsed = ns - kvm->arch.last_tsc_nsec;
> +
> +	/*
> +	 * Special case: identical write to TSC within 5 seconds of
> +	 * another CPU is interpreted as an attempt to synchronize
> +	 * (the 5 seconds is to accomodate host load / swapping).
> +	 *
> +	 * In that case, for a reliable TSC, we can match TSC offsets,
> +	 * or make a best guest using kernel_ns value.
> +	 */
> +	if (data == kvm->arch.last_tsc_write&&  elapsed<  5ULL * NSEC_PER_SEC) {
> +		if (!check_tsc_unstable()) {
> +			offset = kvm->arch.last_tsc_offset;
> +			pr_debug("kvm: matched tsc offset for %llu\n", data);
> +		} else {
> +			u64 tsc_delta = elapsed * __get_cpu_var(cpu_tsc_khz);
> +			tsc_delta = tsc_delta / USEC_PER_SEC;
> +			offset += tsc_delta;
> +			pr_debug("kvm: adjusted tsc offset by %llu\n", tsc_delta);
> +		}
> +		ns = kvm->arch.last_tsc_nsec;
> +	}
> +	kvm->arch.last_tsc_nsec = ns;
> +	kvm->arch.last_tsc_write = data;
> +	kvm->arch.last_tsc_offset = offset;
>    

We'd have a false alarm here during a reset within 5 seconds of boot.  
Does it matter?  Easy to work around by forgetting the state during reset.

>   	kvm_x86_ops->write_tsc_offset(vcpu, offset);
>   	spin_unlock(&kvm->arch.tsc_write_lock);
>
>    


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/