From mboxrd@z Thu Jan 1 00:00:00 1970 From: Denis Plotnikov Subject: Re: [RFC PATCH 0/2] make L2 kvm-clock stable Date: Mon, 10 Jul 2017 10:56:09 +0300 Message-ID: References: <1498647301-130851-1-git-send-email-dplotnikov@virtuozzo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: den@virtuozzo.com, rkagan@virtuozzo.com To: kvm@vger.kernel.org, rkrcmar@redhat.com, pbonzini@redhat.com Return-path: Received: from mail-eopbgr20090.outbound.protection.outlook.com ([40.107.2.90]:51893 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753704AbdGJH6Q (ORCPT ); Mon, 10 Jul 2017 03:58:16 -0400 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: ping! ping! On 03.07.2017 19:12, Denis Plotnikov wrote: > ping! > > On 28.06.2017 13:54, Denis Plotnikov wrote: >> The goal of the series is to make L2's kvm-clock guest stable when >> possible. >> >> It's possible when the L2 is running over L1 with a stable >> paravirtualized >> clocksource. >> >> To acomplish the goal I can see two approaches: >> >> 1. Use currently existing in KVM "monotonic timekeeper shadow". >> >> This approach repeats functionality of time calculation from the >> kerenl >> monotonic timekeeper. To acomplish the goal it's needed to add time >> calculation functions for paravirtualized clocksources to KVM which >> implies repeating the functionality from the timekeeper. >> It seems to me that this approach is not the best one because of code >> repetition, data shadowing, keeping logic consistent with >> timekeeper's one. >> I would consider using the next approach. >> >> 2. Use existing timekeeper functionality with extended interface >> >> This approach deligates all time related calculations to the kernel >> timekeeper instead of having timekeeper shadow and time >> calculating logic >> in KVM. >> Using this approach will allow to remove the monotonic timekeeping >> shadow, >> but ask to change timekeeper interface in a way that will add an >> ability >> to return the timestamp value used for time calculations (if any) >> because this >> value is needed in KVM (and possibly somewhere else in the future). >> >> This patch series implements the 2nd approach (for now, for x86 only). >> Could you please give me some feedback about it? >> >> Denis Plotnikov (2): >> timekeeper: change interface of clocksource reding functions >> KVM: x86: add support of kvm-clock stablity in L2 >> >> arch/x86/hyperv/hv_init.c | 4 +- >> arch/x86/include/asm/kvm_host.h | 2 +- >> arch/x86/include/asm/pvclock.h | 2 +- >> arch/x86/kernel/hpet.c | 4 +- >> arch/x86/kernel/kvmclock.c | 19 ++- >> arch/x86/kernel/pvclock.c | 11 +- >> arch/x86/kernel/tsc.c | 7 +- >> arch/x86/kvm/x86.c | 294 >> ++++++++++-------------------------- >> arch/x86/lguest/boot.c | 2 +- >> arch/x86/platform/uv/uv_time.c | 10 +- >> arch/x86/xen/time.c | 21 ++- >> arch/x86/xen/xen-ops.h | 2 +- >> drivers/clocksource/acpi_pm.c | 12 +- >> drivers/hv/hv_util.c | 6 +- >> include/linux/clocksource.h | 9 +- >> include/linux/timekeeper_internal.h | 2 +- >> include/linux/timekeeping.h | 34 ++++- >> kernel/time/clocksource.c | 4 +- >> kernel/time/jiffies.c | 2 +- >> kernel/time/timekeeping.c | 66 +++++--- >> 20 files changed, 221 insertions(+), 292 deletions(-) >> > -- Best, Denis