Re: [PATCH 09/18] Robust TSC compensation

[Avi Kivity]

On 07/13/2010 05:25 AM, Zachary Amsden wrote:
> Make the match of TSC find TSC writes that are close to each other
> instead of perfectly identical; this allows the compensator to also
> work in migration / suspend scenarios.
>
>    

What scenario exactly?

> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -926,21 +926,27 @@ void guest_write_tsc(struct kvm_vcpu *vcpu, u64 data)
>   	struct kvm *kvm = vcpu->kvm;
>   	u64 offset, ns, elapsed;
>   	struct timespec ts;
> +	s64 sdiff;
>
>   	spin_lock(&kvm->arch.tsc_write_lock);
>   	offset = data - native_read_tsc();
>   	ns = get_kernel_ns();
>   	elapsed = ns - kvm->arch.last_tsc_nsec;
> +	sdiff = data - kvm->arch.last_tsc_write;
> +	if (sdiff<  0)
> +		sdiff = -sdiff;
>
>   	/*
> -	 * Special case: identical write to TSC within 5 seconds of
> +	 * Special case: close 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).
> +	 * The 5 seconds is to accomodate host load / swapping as
> +	 * well as any reset of TSC during the boot process.
>   	 *
>   	 * In that case, for a reliable TSC, we can match TSC offsets,
> -	 * or make a best guest using kernel_ns value.
> +	 * or make a best guest using elapsed value.
>   	 */
> -	if (data == kvm->arch.last_tsc_write&&  elapsed<  5ULL * NSEC_PER_SEC) {
> +	if (sdiff<  nsec_to_cycles(5ULL * NSEC_PER_SEC)&&
> +	    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);
>    

Don't we have to adjust offset to the required different between tsc?  
Or do we assume, that if the guest wrote close enough values, it is 
trying to cleverly compensate for IPI latency?

--
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/