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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[much snippage]

On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
> If the versioning were fixed, I think we could almost get away with:
>
> pvti = pvti for vcpu 0;
>
> ver1 = pvti->version;
> check stable bit;
> rdtsc_barrier, rdtsc, read scale, shift, etc.
> if (pvti->version != ver1) retry;
>
> This guarantees that the tsc came from an interval in which vcpu0's
> kvmclock was *marked* stable.  If vcpu0's kvmclock were genuinely
> stable in that interval, then we'd be fine, but there's a race window
> in which the kvmclock is *not* stable and vcpu 0 wasn't running.

Rik pointed out that this could actually be okay. Apparently vcpu 0 is
somewhat special, and it may actually be impossible to switch from
stable to unstable which a vcpu other than 0 is running and vcpu0
hasn't updated its kvmclock data.

--Andy

>
> Why doesn't KVM just update all of the kvmclock data at once?  (For
> that matter, why is the pvti in guest memory at all?  Wouldn't this
> all be simpler if the kvmclock data were host-allocated so the host
> could write it directly and maybe even share it between guests?)
>
> --Andy



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]