2015-03-24 19:59-0300, Marcelo Tosatti: > On Tue, Mar 24, 2015 at 04:34:12PM +0100, Radim Krčmář wrote: > > 2015-03-23 20:21-0300, Marcelo Tosatti: > > > The following point: > > > > > > 2. per-CPU pvclock time info is updated if the > > > underlying CPU changes. > > > > > > Is not true anymore since "KVM: x86: update pvclock area conditionally, > > > on cpu migration". > > > > I think that the revert doesn't fix point 2.: "KVM: x86: update pvclock > > [...]" changed the host to skip clock update on physical CPU change, but > > guest's task migration notifier isn't tied to it at all. > > "per-CPU pvclock time info is updated if the underlying CPU changes" > is the same as > "always perform clock update on physical CPU change". > > That was a requirement for the original patch, to drop migration > notifiers. > > > (Guest can have all tasks pinned, so the revert changed nothing.) > > > > > Add task migration notification back. > > > > > > Problem noticed by Andy Lutomirski. > > > > What is the problem? > > > > Thanks. > > The problem is this: > > T1) guest thread1 on vcpu1. > T2) guest thread1 on vcpu2. > T3) guest thread1 on vcpu1. > > Inside a pvclock read loop. > > Since the writes by hypervisor of pvclock area are not ordered, > you cannot rely on version being updated _before_ > the rest of pvclock data. > > (in the case above, "has the physical cpu changed" check, inside the > guests thread1, obviously fails). Ah, thanks! so the "KVM: x86: update pvclock area conditionally [...]" has nothing to do with it -- that really confused me. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
