On Mon, May 12, 2014 at 10:26:37PM +0200, Alexander Graf wrote:
>
> On 09.05.14 13:53, Paolo Bonzini wrote:
> >Il 09/05/2014 04:28, Marcelo Tosatti ha scritto:
> >>Alex,
> >>
> >>Unability to upgrade systems is not an excuse to fix the bug in the
> >>wrong place.
> >
> >It may be an excuse to fix
On Fri, May 09, 2014 at 01:53:32PM +0200, Paolo Bonzini wrote:
> Il 09/05/2014 04:28, Marcelo Tosatti ha scritto:
> >Alex,
> >
> >Unability to upgrade systems is not an excuse to fix the bug in the
> >wrong place.
>
> It may be an excuse to fix the bug in both places though.
>
> Paolo
Actually,
On 09.05.14 13:53, Paolo Bonzini wrote:
Il 09/05/2014 04:28, Marcelo Tosatti ha scritto:
Alex,
Unability to upgrade systems is not an excuse to fix the bug in the
wrong place.
It may be an excuse to fix the bug in both places though.
The bug in the kernel should be fixed differently though
Il 09/05/2014 04:28, Marcelo Tosatti ha scritto:
Alex,
Unability to upgrade systems is not an excuse to fix the bug in the
wrong place.
It may be an excuse to fix the bug in both places though.
Paolo
On Thu, May 08, 2014 at 09:21:29AM +0200, Alexander Graf wrote:
>
> On 08.05.14 03:33, Marcelo Tosatti wrote:
> >On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> >>When we migrate we ask the kernel about its current belief on what the guest
> >>time would be. However, I've seen ca
On 08.05.14 03:33, Marcelo Tosatti wrote:
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> When we migrate we ask the kernel about its current belief on what the guest
> time would be. However, I've seen cases where the kvmclock guest structure
> indicates a time more recent than the kvm returned time.
>
> To make sure we
On 08.05.14 01:21, Marcelo Tosatti wrote:
On Tue, May 06, 2014 at 09:18:27AM +0200, Alexander Graf wrote:
On 06.05.14 01:31, Marcelo Tosatti wrote:
On Mon, May 05, 2014 at 08:23:43PM -0300, Marcelo Tosatti wrote:
Hi Alexander,
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
On Tue, May 06, 2014 at 09:54:35PM +0200, Marcin Gibuła wrote:
> >Yes, and it isn't. Any ideas why it's not? This patch really just uses
> >the guest visible kvmclock time rather than the host view of it on
> >migration.
> >
> >There is definitely something very broken on the host's side since it
>
On Tue, May 06, 2014 at 09:18:27AM +0200, Alexander Graf wrote:
>
> On 06.05.14 01:31, Marcelo Tosatti wrote:
> >On Mon, May 05, 2014 at 08:23:43PM -0300, Marcelo Tosatti wrote:
> >>Hi Alexander,
> >>
> >>On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> >>>When we migrate we ask t
Hi all,
On 06/05/14 08:16, Alexander Graf wrote:
>
> On 06.05.14 01:23, Marcelo Tosatti wrote:
>
>> 1) By what algorithm you retrieve
>> and compare time in kvmclock guest structure and KVM_GET_CLOCK.
>> What are the results of the comparison.
>> And whether and backwards time was visible in the
Yes, and it isn't. Any ideas why it's not? This patch really just uses
the guest visible kvmclock time rather than the host view of it on
migration.
There is definitely something very broken on the host's side since it
does return a smaller time than the guest exposed interface indicates.
Don't
What is the host clocksource? (cat
/sys/devices/system/clocksource/clocksource0/current_clocksource).
tsc
And kernel version?
3.12.17
But I've seen this problem on earlier versions as well (3.8, 3.10).
--
mg
On 06.05.14 01:31, Marcelo Tosatti wrote:
On Mon, May 05, 2014 at 08:23:43PM -0300, Marcelo Tosatti wrote:
Hi Alexander,
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
When we migrate we ask the kernel about its current belief on what the guest
time would be.
KVM_GET_CLOCK w
On 06.05.14 01:23, Marcelo Tosatti wrote:
Hi Alexander,
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
When we migrate we ask the kernel about its current belief on what the guest
time would be.
KVM_GET_CLOCK which returns the time in "struct kvm_clock_data".
Yes :)
How
On 06.05.14 01:27, Marcelo Tosatti wrote:
On Mon, May 05, 2014 at 08:26:04PM +0200, Marcin Gibuła wrote:
is it possible to have kvmclock jumping forward?
Because I've reproducible case when at about 1 per 20 vm restores, VM freezes
for couple of hours and then resumes with date few hundreds y
On Mon, May 05, 2014 at 08:23:43PM -0300, Marcelo Tosatti wrote:
> Hi Alexander,
>
> On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> > When we migrate we ask the kernel about its current belief on what the guest
> > time would be.
>
> KVM_GET_CLOCK which returns the time in "st
Marcin,
Can you provide detailed instructions on how to reproduce the problem?
Thanks
On Mon, May 05, 2014 at 08:27:10PM -0300, Marcelo Tosatti wrote:
> On Mon, May 05, 2014 at 08:26:04PM +0200, Marcin Gibuła wrote:
> > >>is it possible to have kvmclock jumping forward?
> > >>
> > >>Because I'v
On Mon, May 05, 2014 at 08:26:04PM +0200, Marcin Gibuła wrote:
> >>is it possible to have kvmclock jumping forward?
> >>
> >>Because I've reproducible case when at about 1 per 20 vm restores, VM
> >>freezes for couple of hours and then resumes with date few hundreds years
> >>ahead. Happens only
Hi Alexander,
On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote:
> When we migrate we ask the kernel about its current belief on what the guest
> time would be.
KVM_GET_CLOCK which returns the time in "struct kvm_clock_data".
> However, I've seen cases where the kvmclock guest stru
is it possible to have kvmclock jumping forward?
Because I've reproducible case when at about 1 per 20 vm restores, VM freezes
for couple of hours and then resumes with date few hundreds years ahead.
Happens only with kvmclock.
And this patch seems to fix very similar issue so maybe it's all t
> Am 05.05.2014 um 19:46 schrieb Marcin Gibuła :
>
> W dniu 2014-05-05 15:51, Alexander Graf pisze:
>> When we migrate we ask the kernel about its current belief on what the guest
>> time would be. However, I've seen cases where the kvmclock guest structure
>> indicates a time more recent than t
W dniu 2014-05-05 15:51, Alexander Graf pisze:
When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the kvm returned time.
Hi,
is it possible to have kvmclock ju
When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the kvm returned time.
To make sure we never go backwards, calculate what the guest would have seen
as time at t
24 matches
Mail list logo
