From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752947AbdDMK3c (ORCPT ); Thu, 13 Apr 2017 06:29:32 -0400 Received: from mail-cys01nam02on0055.outbound.protection.outlook.com ([104.47.37.55]:32470 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750735AbdDMK33 (ORCPT ); Thu, 13 Apr 2017 06:29:29 -0400 From: Alok Kataria To: "jgross@suse.com" CC: "boris.ostrovsky@oracle.com" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "virtualization@lists.linux-foundation.org" , "x86@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 10/11] vmware: set cpu capabilities during platform initialization Thread-Topic: [PATCH v2 10/11] vmware: set cpu capabilities during platform initialization Thread-Index: AQHStD5depA2LIcNK0C+IOAgqyRRPqHDGyGA Date: Thu, 13 Apr 2017 10:29:27 +0000 Message-ID: <1492079789.5342.0.camel@vmware.com> References: <20170413101116.723-1-jgross@suse.com> <20170413101116.723-11-jgross@suse.com> In-Reply-To: <20170413101116.723-11-jgross@suse.com> Reply-To: Alok Kataria Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [27.250.19.131] x-microsoft-exchange-diagnostics: 1;DM2PR05MB365;7:VYXTi6oGxrCpHCtWcvhS7OCgooEHdIaiaMBZnbFKwQjQThwTbA9R3KGBIaoe6PUdmbYnOWjAIfbLPkHehCZ5a66+g8S1YkxgTB88FZZkifqCGWe6A0ViICG++55JN3K13FZJg9MxS0uWrFZX7xlPVRZdzT2jeyVxk1vajEXkEhydK6yeaFRVa+9FV8k7tr+LAVkIEobChi9nEVje0LksoUvFapCVSMvzqH5IICVYQ6yroIe8DYb1EaIlrm/IQeoxVfiDq/XlBrCIJK8KDTvuUMgM1QBS+/SGg48j+mPgY4MBP8e6Hi4/hTWypQTz/PAsV3oxBpV+BQ4fuc9X/rfHtg==;20:TCFhR1ldtuoaMC5E/ZCgU429M6rvBZOYEIdU144uutY63FotKfXmDUGA+mTo9+XohygUCTL7+olIM0AOxMoESk/thO5ZkvWqmRs2gClxOgE9IS2tVSlbj1S5+pE/Ln+BZXAj5ed+uuBrjdqA+GmZglZcKRdthOKx78ZvdMgqxTs= x-ms-office365-filtering-correlation-id: 6b75f63a-5b18-4543-b1db-08d48257f662 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075);SRVR:DM2PR05MB365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148);SRVR:DM2PR05MB365;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB365; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(39410400002)(39450400003)(39400400002)(39850400002)(24454002)(377424004)(6486002)(2351001)(3280700002)(6506006)(6436002)(86362001)(2906002)(6246003)(6916009)(229853002)(33646002)(2501003)(36756003)(2900100001)(103116003)(4326008)(54906002)(43066003)(5640700003)(99286003)(3450700001)(3846002)(6512007)(3660700001)(50986999)(66066001)(6116002)(102836003)(2950100002)(189998001)(54356999)(305945005)(76176999)(7736002)(122556002)(8676002)(1730700003)(81166006)(53936002)(8936002)(25786009)(38730400002)(5660300001)(110136004);DIR:OUT;SFP:1101;SCL:1;SRVR:DM2PR05MB365;H:DM2PR05MB366.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4F184592D26638428E7677F1C4C80E94@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2017 10:29:27.1491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB365 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3DATkgQ018566 On Thu, 2017-04-13 at 12:11 +0200, Juergen Gross wrote: > There is no need to set the same capabilities for each cpu > individually. This can be done for all cpus in platform initialization. Looks reasonable to me. Acked-by: Alok Kataria Thanks, Alok > > Cc: Alok Kataria > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x86@kernel.org > Cc: virtualization@lists.linux-foundation.org > Signed-off-by: Juergen Gross > --- > arch/x86/kernel/cpu/vmware.c | 39 ++++++++++++++++++++------------------- > 1 file changed, 20 insertions(+), 19 deletions(-) > > diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c > index 22403a28caf5..40ed26852ebd 100644 > --- a/arch/x86/kernel/cpu/vmware.c > +++ b/arch/x86/kernel/cpu/vmware.c > @@ -113,6 +113,24 @@ static void __init vmware_paravirt_ops_setup(void) > #define vmware_paravirt_ops_setup() do {} while (0) > #endif > > +/* > + * VMware hypervisor takes care of exporting a reliable TSC to the guest. > + * Still, due to timing difference when running on virtual cpus, the TSC can > + * be marked as unstable in some cases. For example, the TSC sync check at > + * bootup can fail due to a marginal offset between vcpus' TSCs (though the > + * TSCs do not drift from each other). Also, the ACPI PM timer clocksource > + * is not suitable as a watchdog when running on a hypervisor because the > + * kernel may miss a wrap of the counter if the vcpu is descheduled for a > + * long time. To skip these checks at runtime we set these capability bits, > + * so that the kernel could just trust the hypervisor with providing a > + * reliable virtual TSC that is suitable for timekeeping. > + */ > +static void __init vmware_set_capabilities(void) > +{ > + setup_force_cpu_cap(X86_FEATURE_CONSTANT_TSC); > + setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); > +} > + > static void __init vmware_platform_setup(void) > { > uint32_t eax, ebx, ecx, edx; > @@ -152,6 +170,8 @@ static void __init vmware_platform_setup(void) > #ifdef CONFIG_X86_IO_APIC > no_timer_check = 1; > #endif > + > + vmware_set_capabilities(); > } > > /* > @@ -176,24 +196,6 @@ static uint32_t __init vmware_platform(void) > return 0; > } > > -/* > - * VMware hypervisor takes care of exporting a reliable TSC to the guest. > - * Still, due to timing difference when running on virtual cpus, the TSC can > - * be marked as unstable in some cases. For example, the TSC sync check at > - * bootup can fail due to a marginal offset between vcpus' TSCs (though the > - * TSCs do not drift from each other). Also, the ACPI PM timer clocksource > - * is not suitable as a watchdog when running on a hypervisor because the > - * kernel may miss a wrap of the counter if the vcpu is descheduled for a > - * long time. To skip these checks at runtime we set these capability bits, > - * so that the kernel could just trust the hypervisor with providing a > - * reliable virtual TSC that is suitable for timekeeping. > - */ > -static void vmware_set_cpu_features(struct cpuinfo_x86 *c) > -{ > - set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); > - set_cpu_cap(c, X86_FEATURE_TSC_RELIABLE); > -} > - > /* Checks if hypervisor supports x2apic without VT-D interrupt remapping. */ > static bool __init vmware_legacy_x2apic_available(void) > { > @@ -206,7 +208,6 @@ static bool __init vmware_legacy_x2apic_available(void) > const __refconst struct hypervisor_x86 x86_hyper_vmware = { > .name = "VMware", > .detect = vmware_platform, > - .set_cpu_features = vmware_set_cpu_features, > .init_platform = vmware_platform_setup, > .x2apic_available = vmware_legacy_x2apic_available, > };