Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 24.08.2017 11:00, Paolo Bonzini wrote: On 23/08/2017 18:02, Paolo Bonzini wrote: More duct tape would have been just: - if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC) + mode = READ_ONCE(pvclock_gtod_data.clock.vclock_mode); + if (mode != VCLOCK_TSC && +

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 24.08.2017 11:00, Paolo Bonzini wrote: On 23/08/2017 18:02, Paolo Bonzini wrote: More duct tape would have been just: - if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC) + mode = READ_ONCE(pvclock_gtod_data.clock.vclock_mode); + if (mode != VCLOCK_TSC && +

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 23/08/2017 18:02, Paolo Bonzini wrote: > > More duct tape would have been just: > > - if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC) > + mode = READ_ONCE(pvclock_gtod_data.clock.vclock_mode); > + if (mode != VCLOCK_TSC && > + (mode != VCLOCK_PVCLOCK ||

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 23/08/2017 18:02, Paolo Bonzini wrote: > > More duct tape would have been just: > > - if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC) > + mode = READ_ONCE(pvclock_gtod_data.clock.vclock_mode); > + if (mode != VCLOCK_TSC && > + (mode != VCLOCK_PVCLOCK ||

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 23/08/2017 14:45, Thomas Gleixner wrote: > So the real question is how to ensure that: > > 1) None of the update functions is in progress > > 2) The update is propagated via the existing mechanisms > > The whole live migration magic is orchestrated by qemu and the kernel. So > it's

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 23/08/2017 14:45, Thomas Gleixner wrote: > So the real question is how to ensure that: > > 1) None of the update functions is in progress > > 2) The update is propagated via the existing mechanisms > > The whole live migration magic is orchestrated by qemu and the kernel. So > it's

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Tue, 22 Aug 2017, Paolo Bonzini wrote: > Regarding the "why is it best" part. Right now, the hypervisor makes a > copy of the timekeeper information in order to prepare the stable kvmclock. > This code is very much tied to the TSC. However, a snapshot of the timekeeper > information is almost

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Tue, 22 Aug 2017, Paolo Bonzini wrote: > Regarding the "why is it best" part. Right now, the hypervisor makes a > copy of the timekeeper information in order to prepare the stable kvmclock. > This code is very much tied to the TSC. However, a snapshot of the timekeeper > information is almost

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

> I still don't feel my questions have been well answered. Its really > not clear to me why, in order to allow the level-2 guest to use a vdso > that the answer is to export more data through the entire stack rather > then to make the kvmclock to be usable from the vsyscall. Thanks, this helps.

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

> I still don't feel my questions have been well answered. Its really > not clear to me why, in order to allow the level-2 guest to use a vdso > that the answer is to export more data through the entire stack rather > then to make the kvmclock to be usable from the vsyscall. Thanks, this helps.

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Mon, Aug 21, 2017 at 1:40 AM, Denis Plotnikov wrote: > ping! > I still don't feel my questions have been well answered. Its really not clear to me why, in order to allow the level-2 guest to use a vdso that the answer is to export more data through the entire stack

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Mon, Aug 21, 2017 at 1:40 AM, Denis Plotnikov wrote: > ping! > I still don't feel my questions have been well answered. Its really not clear to me why, in order to allow the level-2 guest to use a vdso that the answer is to export more data through the entire stack rather then to make the

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

ping! On 02.08.2017 20:11, Paolo Bonzini wrote: On 02/08/2017 18:49, John Stultz wrote: On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov wrote: V4: * removed "is stable" function with vague definition of stability there is the only function which does time

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

ping! On 02.08.2017 20:11, Paolo Bonzini wrote: On 02/08/2017 18:49, John Stultz wrote: On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov wrote: V4: * removed "is stable" function with vague definition of stability there is the only function which does time with cycle stamp getting

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 18:49, John Stultz wrote: > On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov > wrote: >> V4: >> * removed "is stable" function with vague definition of stability >> there is the only function which does time with cycle stamp getting >> * some

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 18:49, John Stultz wrote: > On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov > wrote: >> V4: >> * removed "is stable" function with vague definition of stability >> there is the only function which does time with cycle stamp getting >> * some variables renamed >> * some

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On Wed, Aug 2, 2017 at 7:38 AM, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller once > * atomic64_t

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 16:38, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller once > * atomic64_t usage is

Re: [PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

On 02/08/2017 16:38, Denis Plotnikov wrote: > V4: > * removed "is stable" function with vague definition of stability > there is the only function which does time with cycle stamp getting > * some variables renamed > * some patches split into smaller once > * atomic64_t usage is

[PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

V4: * removed "is stable" function with vague definition of stability there is the only function which does time with cycle stamp getting * some variables renamed * some patches split into smaller once * atomic64_t usage is replaced with atomic_t V3: Changing the timekeeper

[PATCH v4 00/10] make L2's kvm-clock stable, get rid of pvclock_gtod_copy in KVM

V4: * removed "is stable" function with vague definition of stability there is the only function which does time with cycle stamp getting * some variables renamed * some patches split into smaller once * atomic64_t usage is replaced with atomic_t V3: Changing the timekeeper