Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"

From: Andy Lutomirski <luto@amacapital.net>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm-devel <kvm@vger.kernel.org>, stable <stable@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: x86: kvm: Revert "remove sched notifier for cross-cpu migrations"
Date: Tue, 24 Mar 2015 15:33:44 -0700	[thread overview]
Message-ID: <CALCETrVR6zb6Nvb+tV9qHvDRtx3fhsinBrd9YwNgT6cvAg4a3Q@mail.gmail.com> (raw)
In-Reply-To: <20150324153412.GB21710@potion.brq.redhat.com>

On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář <rkrcmar@redhat.com> 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.
> (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?

The kvmclock spec says that the host will increment a version field to
an odd number, then update stuff, then increment it to an even number.
The host is buggy and doesn't do this, and the result is observable
when one vcpu reads another vcpu's kvmclock data.

Since there's no good way for a guest kernel to keep its vdso from
reading a different vcpu's kvmclock data, this is a real corner-case
bug.  This patch allows the vdso to retry when this happens.  I don't
think it's a great solution, but it should mostly work.

--Andy