From patchwork Thu Jun 21 15:06:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= X-Patchwork-Id: 10480009 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8C126604D3 for ; Thu, 21 Jun 2018 15:06:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A9E727031 for ; Thu, 21 Jun 2018 15:06:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6EBAB29224; Thu, 21 Jun 2018 15:06:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, FROM_EXCESS_BASE64, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 00D7D27031 for ; Thu, 21 Jun 2018 15:06:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932966AbeFUPGw (ORCPT ); Thu, 21 Jun 2018 11:06:52 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:45956 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932747AbeFUPGw (ORCPT ); Thu, 21 Jun 2018 11:06:52 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AF9EE401C7E9; Thu, 21 Jun 2018 15:06:51 +0000 (UTC) Received: from flask (unknown [10.43.2.80]) by smtp.corp.redhat.com (Postfix) with SMTP id 5030B1C65D; Thu, 21 Jun 2018 15:06:49 +0000 (UTC) Received: by flask (sSMTP sendmail emulation); Thu, 21 Jun 2018 17:06:48 +0200 Date: Thu, 21 Jun 2018 17:06:48 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: mpagano@gentoo.org, Andreas Steinmetz Cc: kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org Subject: [PATCH] x86/kvmclock: set pvti_cpu0_va after enabling kvmclock Message-ID: <20180621150645.GB8203@flask> References: <20180621121325.9326-1-mpagano@gentoo.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180621121325.9326-1-mpagano@gentoo.org> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 21 Jun 2018 15:06:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 21 Jun 2018 15:06:51 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'rkrcmar@redhat.com' RCPT:'' Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 2018-06-21 08:13-0400, mpagano@gentoo.org: > From: Mike Pagano > > setup_vsyscall_timeinfo() is only defined for x86_64, thus > clock_set_pvti_cpu0_va() does not get called resulting in > the failure of ptp_kvm initialization for Linux X86_32 guests. > The result of this being that the 32 bit guest userspace has > no /dev/ptp0 device. > > See Gentoo bug 658544 located at the following link: > https://bugs.gentoo.org/658544 > > Signed-off-by: Mike Pagano > Signed-off-by: Andreas Steinmetz > --- > arch/x86/kernel/kvmclock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > index bf8d1eb7fca3..6aee5c6265b3 100644 > --- a/arch/x86/kernel/kvmclock.c > +++ b/arch/x86/kernel/kvmclock.c > @@ -350,7 +350,7 @@ void __init kvmclock_init(void) > > int __init kvm_setup_vsyscall_timeinfo(void) > { > -#ifdef CONFIG_X86_64 > +#ifdef CONFIG_X86_64 || defined(CONFIG_X86_32) The code should actually read "#if defined(...", or be omitted as we have only these two x86 variants. The correct variant might cause unexpected bugs by enabling the vsyscall on 32 bit kernels. Please check that the following patch fixes your problem as well, thanks. ---8<--- pvti_cpu0_va is the address of shared kvmclock data structure. pvti_cpu0_va is currently kept unset (1) on 32 bit systems, (2) when kvmclock vsyscall is disabled, and (3) if kvmclock is not stable. This poses a problem, because kvm_ptp needs pvti_cpu0_va, but (1) can work on 32 bit, (2) has little relation to the vsyscall, and (3) does not need stable kvmclock (although kvmclock won't be used for system clock if it's not stable, so kvm_ptp is pointless in that case). Expose pvti_cpu0_va whenever kvmclock is enabled to allow all users to work with it. This fixes a regression found on Gentoo: https://bugs.gentoo.org/658544. Fixes: 9f08890ab906 ("x86/pvclock: add setter for pvclock_pvti_cpu0_va") Reported-by: Andreas Steinmetz Signed-off-by: Radim Krčmář --- arch/x86/kernel/kvmclock.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index bf8d1eb7fca3..46ffa8327563 100644 --- a/arch/x86/kernel/kvmclock.c +++ b/arch/x86/kernel/kvmclock.c @@ -319,6 +319,8 @@ void __init kvmclock_init(void) printk(KERN_INFO "kvm-clock: Using msrs %x and %x", msr_kvm_system_time, msr_kvm_wall_clock); + pvclock_set_pvti_cpu0_va(hv_clock); + if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT)) pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT); @@ -366,14 +368,11 @@ int __init kvm_setup_vsyscall_timeinfo(void) vcpu_time = &hv_clock[cpu].pvti; flags = pvclock_read_flags(vcpu_time); - if (!(flags & PVCLOCK_TSC_STABLE_BIT)) { - put_cpu(); - return 1; - } - - pvclock_set_pvti_cpu0_va(hv_clock); put_cpu(); + if (!(flags & PVCLOCK_TSC_STABLE_BIT)) + return 1; + kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK; #endif return 0;