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, 3 Jul 2017 19:12:10 +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-ve1eur01on0115.outbound.protection.outlook.com ([104.47.1.115]:62917 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752769AbdGCQMu (ORCPT ); Mon, 3 Jul 2017 12:12:50 -0400 In-Reply-To: <1498647301-130851-1-git-send-email-dplotnikov@virtuozzo.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: 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