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 &&
+
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 || !pvclock_nest
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 reason
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
> 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.
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 kvmc
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
*
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 patc
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 usag
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 replace
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 interfac
11 matches
Mail list logo