search for: pvclock_clocksource_read

...00011200028d6400 0000000000000010 000000000000f9e0 ffff8800024a7fd8 [163440.613494] 0000000000015780 0000000000015780 ffff8800024ab170 ffff8800024ab468 [163440.613503] Call Trace: [163440.613520] [<ffffffff810e7e95>] ? kmem_cache_alloc+0x8c/0xf0 [163440.613528] [<ffffffff8102ddc0>] ? pvclock_clocksource_read+0x3a/0x8b [163440.613537] [<ffffffff8130b5f1>] ? io_schedule+0x73/0xb7 [163440.613546] [<ffffffff8118053b>] ? get_request_wait+0xf0/0x188 [163440.613553] [<ffffffff81065d0a>] ? autoremove_wake_function+0x0/0x2e [163440.613559] [<ffffffff811808ca>] ? __make_request+0x2f7/...

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

Respin of the paravirt clock patch series. On the host side the kvm paravirt clock is made compatible with the xen clock. On the guest side some xen code has been factored out into a separate source file shared by both kvm and xen clock implementations. This time it should work ok for kvm smp guests ;) cheers, Gerd

...a4f07c1 100644 --- a/arch/x86/kernel/pvclock.c +++ b/arch/x86/kernel/pvclock.c @@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src) static atomic64_t last_value = ATOMIC64_INIT(0); +void pvclock_resume(void) +{ + atomic64_set(&last_value, 0); +} + cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src) { struct pvclock_shadow_time shadow; diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index b2bb5aa..5da5e53 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -426,6 +426,8 @@ void xen_timer_resume(void) { int cpu; + pvclock_resume(); +...

...a4f07c1 100644 --- a/arch/x86/kernel/pvclock.c +++ b/arch/x86/kernel/pvclock.c @@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src) static atomic64_t last_value = ATOMIC64_INIT(0); +void pvclock_resume(void) +{ + atomic64_set(&last_value, 0); +} + cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src) { struct pvclock_shadow_time shadow; diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index b2bb5aa..5da5e53 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -426,6 +426,8 @@ void xen_timer_resume(void) { int cpu; + pvclock_resume(); +...

...a4f07c1 100644 --- a/arch/x86/kernel/pvclock.c +++ b/arch/x86/kernel/pvclock.c @@ -120,6 +120,11 @@ unsigned long pvclock_tsc_khz(struct pvclock_vcpu_time_info *src) static atomic64_t last_value = ATOMIC64_INIT(0); +void pvclock_resume(void) +{ + atomic64_set(&last_value, 0); +} + cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src) { struct pvclock_shadow_time shadow; diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index b2bb5aa..5da5e53 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -426,6 +426,8 @@ void xen_timer_resume(void) { int cpu; + pvclock_resume(); +...

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round, with a bunch of changes in the host code according to Avi's review comments and some minor code tweaks. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. cheers, Gerd

...1fa5b880 0000000000000082 0000000000000000 ffff88011e45bb44 [ 240.575508] ffff88011e45bcc8 ffffffff8102cdac 000000000000f9e0 ffff88011e45bfd8 [ 240.578827] 0000000000015780 0000000000015780 ffff88011c7ce2e0 ffff88011c7ce5d8 [ 240.580502] Call Trace: [ 240.581132] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b [ 240.582427] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b [ 240.583869] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46 [ 240.585034] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46 [ 240.586087] [<ffffffff812f9939>] ? io_schedule+0x73/0xb7 [ 240.587287]...

...1fa5b880 0000000000000082 0000000000000000 ffff88011e45bb44 [ 240.575508] ffff88011e45bcc8 ffffffff8102cdac 000000000000f9e0 ffff88011e45bfd8 [ 240.578827] 0000000000015780 0000000000015780 ffff88011c7ce2e0 ffff88011c7ce5d8 [ 240.580502] Call Trace: [ 240.581132] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b [ 240.582427] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b [ 240.583869] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46 [ 240.585034] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46 [ 240.586087] [<ffffffff812f9939>] ? io_schedule+0x73/0xb7 [ 240.587287]...

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

paravirt clock source patches, next round. There is now a pvclock-abi.h file with the structs and some longish comments in it and everybody is switched over to use the stuff in there. Some minor tweaks after super-fast review by Jeremy. The queue is on top of the kvm git tree. The first two patches should have no kvm dependencies and should apply to linus tree just fine. cheers, Gerd

...t;] __raid_run_ops+0x4e8/0x660 [raid456] kernel: [<ffffffffa00e81a9>] ? ops_run_io+0x29/0x740 [raid456] kernel: [<ffffffffa00e1685>] ? handle_stripe_dirtying+0x335/0x450 [raid456] kernel: [<ffffffffa00e91c3>] handle_stripe+0x903/0xec0 [raid456] kernel: [<ffffffff81044298>] ? pvclock_clocksource_read+0x58/0xd0 kernel: [<ffffffffa00e9afa>] handle_active_stripes+0x19a/0x280 [raid456] kernel: [<ffffffffa00e9dd8>] raid5d+0x1f8/0x350 [raid456] kernel: [<ffffffff8100a350>] ? xen_clocksource_read+0x20/0x30 kernel: [<ffffffff8156d23e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30 ker...

Hi, In view of the problems I was having with DomU network timeout after a live migration (I posted that problems here a while ago but never got anything except from private emails) I finally updated my Debian/Squeeze Dom0s last night to a new kernel, from 2.6.32-23 to 2.6.32-26. Now live migration just hangs...Any ideas? Xen-related Debian packages (all from Debian repositary, except drbd

...page+0x177/0x420 [229995.585770] [<ffffffff811360f1>] __get_user_pages+0x1d1/0x590 [229995.585886] [<ffffffff8111ea19>] ? add_page_to_unevictable_list+0x99/0xc0 [229995.586012] [<ffffffff811374be>] __mlock_vma_pages_range+0xbe/0x1b0 [229995.586137] [<ffffffff8106db5e>] ? pvclock_clocksource_read+0x4e/0xc0 [229995.586260] [<ffffffff8113773f>] mlock_fixup+0x18f/0x220 [229995.586463] [<ffffffff81137857>] do_mlockall+0x87/0xa0 [229995.586645] [<ffffffff8113797f>] sys_mlockall+0xaf/0xe0 [229995.586754] [<ffffffff81049242>] system_call_fastpath+0x16/0x1b [229995.58686...

...fffffff8100c608>] ? pin_pagetable_pfn+0x29/0x36 [22077.214570]  [<ffffffff810cd2da>] ? __pte_alloc+0x6b/0xc6 [22077.214628]  [<ffffffff810cb18c>] ? pmd_alloc+0x28/0x5b [22077.214685]  [<ffffffff810cd403>] ? handle_mm_fault+0xce/0x80f [22077.214743]  [<ffffffff8102ddac>] ? pvclock_clocksource_read+0x3a/0x8b [22077.214803]  [<ffffffff8130e3b6>] ? do_page_fault+0x2e0/0x2fc [22077.214861]  [<ffffffff8130c255>] ? page_fault+0x25/0x30 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users