On Tue, 7 Feb 2012, Marcelo Tosatti wrote:
>
> Upon resume from hibernation, CPU 0's hvclock area contains the old
> values for system_time and tsc_timestamp. It is necessary for the
> hypervisor to update these values with uptodate ones before the CPU uses
> them.
>
> Abstract TSC's save/restore
On 02/13/2012 05:52 PM, Marcelo Tosatti wrote:
> > > {
> > >+ x86_platform.restore_sched_clock_state();
> > Isn't it too early? It is scarry to say hypervisor to write to some
> > memory location and than completely replace page-tables and half of
> > cpu state in __restore_processor_state. Would
On (Mon) 13 Feb 2012 [11:07:27], Marcelo Tosatti wrote:
>
> Upon resume from hibernation, CPU 0's hvclock area contains the old
> values for system_time and tsc_timestamp. It is necessary for the
> hypervisor to update these values with uptodate ones before the CPU uses
> them.
>
> Abstract TSC's
On Mon, Feb 13, 2012 at 04:20:24PM +0100, Igor Mammedov wrote:
> On 02/13/2012 02:07 PM, Marcelo Tosatti wrote:
> >
> >Upon resume from hibernation, CPU 0's hvclock area contains the old
> >values for system_time and tsc_timestamp. It is necessary for the
> >hypervisor to update these values with u
On 02/13/2012 02:07 PM, Marcelo Tosatti wrote:
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_c
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_clock_state functions and use
restore_state to wri
On (Fri) 10 Feb 2012 [10:33:37], Marcelo Tosatti wrote:
> On Fri, Feb 10, 2012 at 10:32:16AM -0200, Marcelo Tosatti wrote:
> > On Fri, Feb 10, 2012 at 03:32:11PM +0530, Amit Shah wrote:
> > > On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
> > >
> > > > Stalls are probably caused by uninitia
On (Fri) 10 Feb 2012 [13:43:05], Igor Mammedov wrote:
> Another thing is to try smp guest without kvmclock and see if it helps.
> It might be just something else.
Nope, it's related to kvmclock.
Amit
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
On (Fri) 10 Feb 2012 [21:58:47], Igor Mammedov wrote:
> BTW Amit,
> your config doesn't have CONFIG_KVM_GUEST set, which causes primary cpu clock
> to be
> uninitialized too in case of SMP kernel.
Interesting. I didn't notice that. However, if I enable that option,
resume fails for me even the
I've to revoke my ack and say NAK to this patch. Patch itself is in right
direction but clock restore happens too late.
With patch I've used to hunt down overflow for cpu hotplug
(maybe it will be better for it to be in kernel, which will help to detect
overflow problem without spending a lot of
On (Fri) 10 Feb 2012 [10:32:16], Marcelo Tosatti wrote:
> On Fri, Feb 10, 2012 at 03:32:11PM +0530, Amit Shah wrote:
> > On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
> >
> > > Stalls are probably caused by uninitialized percpu hv_clock, with
> > > following patch I don't see stalls. Altho
On 02/10/2012 01:33 PM, Marcelo Tosatti wrote:
On Fri, Feb 10, 2012 at 10:32:16AM -0200, Marcelo Tosatti wrote:
On Fri, Feb 10, 2012 at 03:32:11PM +0530, Amit Shah wrote:
On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
Stalls are probably caused by uninitialized percpu hv_clock, with
fo
On Fri, Feb 10, 2012 at 10:32:16AM -0200, Marcelo Tosatti wrote:
> On Fri, Feb 10, 2012 at 03:32:11PM +0530, Amit Shah wrote:
> > On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
> >
> > > Stalls are probably caused by uninitialized percpu hv_clock, with
> > > following patch I don't see stal
On Fri, Feb 10, 2012 at 03:32:11PM +0530, Amit Shah wrote:
> On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
>
> > Stalls are probably caused by uninitialized percpu hv_clock, with
> > following patch I don't see stalls. Although I might be just lucky.
> > http://git.kernel.org/?p=virt/kvm/k
On (Fri) 10 Feb 2012 [05:11:00], Igor Mammedov wrote:
> Could you send me your .config and commit id of kernel you are using?
Kernel's based on bd3ce7d57c380af110c86d19e256115d0e7053ca plus your
commit + Marcelo's patch.
config is attached below.
#
# Automatically generated file; DO NOT EDIT.
#
.com, x...@kernel.org, johns...@us.ibm.com, r...@redhat.com,
> a...@redhat.com
> Sent: Friday, February 10, 2012 11:02:11 AM
> Subject: Re: x86: kvmclock: abstract save/restore sched_clock_state
>
> On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
>
> > Stalls are probabl
On (Thu) 09 Feb 2012 [16:13:29], Igor Mammedov wrote:
> Stalls are probably caused by uninitialized percpu hv_clock, with
> following patch I don't see stalls. Although I might be just lucky.
> http://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=e2971ac7e1d186af059e088d305496c5cb47d487
Your comm
On 02/09/2012 01:27 PM, Amit Shah wrote:
On (Tue) 07 Feb 2012 [19:05:42], Marcelo Tosatti wrote:
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the
On (Tue) 07 Feb 2012 [19:05:42], Marcelo Tosatti wrote:
>
> Upon resume from hibernation, CPU 0's hvclock area contains the old
> values for system_time and tsc_timestamp. It is necessary for the
> hypervisor to update these values with uptodate ones before the CPU uses
> them.
>
> Abstract TSC's
On 02/07/2012 10:05 PM, Marcelo Tosatti wrote:
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_c
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_clock_state functions and use
restore_state to wri
21 matches
Mail list logo
