[lucid PATCH] fix smp kvm guests on AMD

Serge E. Hallyn serge.hallyn at canonical.com
Mon Mar 7 19:57:39 UTC 2011


Quoting Stefan Bader (stefan.bader at canonical.com):

Thanks for the review, Stefan.  Great catches.

> I looked through the patches and have a few questions/remarks:
> 
> Patch #2 seems to work around some changes missing from
> 
> commit 759379dd68c2885d1fafa433083d4487e710a685
> Author: Zachary Amsden <zamsden at redhat.com>
> Date:   Thu Aug 19 22:07:25 2010 -1000
> 
>     KVM: x86: Add helper functions for time computation
> 
> that patch replaces
>  	ktime_get_ts(&ts);
>  	monotonic_to_bootbased(&ts);
> 	[timespec_to_ns(&ts);]
> by
> 	kernel_ns = get_kernel_ns()
> 
> which is all done within the section of disabled interrupts, so I probably would
> move the assignment of kernel_ns up before local_irq_restore().

Sounds good.

> Also in patch#2, the upstream patch does this:
> 
> /* With all the info we got, fill in the values */
> vcpu->hv_clock.tsc_timestamp = tsc_timestamp;
> 
> This seems to be missing in the backport.

Yes, I missed that one, and clearly it's necessary.

> And finally in patch#3 last_guest_tsc is set right at the beginning but the
> upstream patch had that later in the section that was assigning last_kernel_ns.
> 
> @@ -1095,6 +1095,7 @@ static int kvm_write_guest_time(struct kvm_vcpu *v)
>         vcpu->hv_clock.tsc_timestamp = tsc_timestamp;
>         vcpu->hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
>         vcpu->last_kernel_ns = kernel_ns;
> +       vcpu->last_guest_tsc = tsc_timestamp;
>         vcpu->hv_clock.flags = 0;

Feh, that's how the first version of my patch did it.  Messed up in
the split.

Are you planning to just fix these on your end?

> One not directly related note: when checking whether this could have effects on
> the lucid-ec2 branch, I noted that the xen code also has some scale_delta in its
> code. It seems separated enough to be unaffected. But then maybe we actually
> want to look closer there. Maybe there is the same problem in that code (I did
> not look closer, yet).

I'd worry about doing that without reports from xen users.

thanks,
-serge




More information about the kernel-team mailing list