Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp544766pxj; Thu, 13 May 2021 10:51:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3+qYvpcPVsTjfkIvmg6jTQpLzPI5EcgLhbH4mHH/nMo5OmULUbclhOouFQ+y4ZWslFEvh X-Received: by 2002:aca:44a:: with SMTP id 71mr29766115oie.39.1620928265853; Thu, 13 May 2021 10:51:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620928265; cv=none; d=google.com; s=arc-20160816; b=fpF1rlcLKiem9EjfsdSzCHeZTCB8tYlOeAFYpP5E0mf5MGcFo8t0V+Tp10CGXxyZd6 93wJ+TJ9VgU7OC9I/P7TueDQVdrHOs3XuNT62E1cOTWb8tUc4XVrgzMQCqNBiubQYuf5 Ee7rcBBlRNfdw8QLXzm8ixqdU8COmLMd/DsHT/DysOXSozIXa2qcZQRsreMre7YCQwZj liGn5DAorzkcSGJ6R1knneqHfdWD/6bEEgM0B7VkqGLCwXTrN09PfmkNVt2vI/9RQyjc KqEfLO1OYqAv98rxtYyuBPblFIEg/poBj14b/OA0QW/wH+RsYkla2YH5Pw+saZX6SENP T9Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:ironport-sdr:ironport-sdr; bh=msz0bESoiw3vAf16ZHPWQy/DpykY69WPgBOUcu0TLm8=; b=FEWypIyTmL4gG6IvEPrK1DA3G859dJJgoxMs8MgQmZChXFbIl1dFHD1IBAST6iM1bc XtpujMhfaMswz8/rD0WIaiq9H1EFmgfeCvl9tUc9r7WomwfXOHmt93BLxH0cIzt/aMJ8 CYl5e18OP43yJnQmRML/oEYdKeElK3fUAXwFJkgXJ7AyY29UtxR6CBx/HxGfydQCQsSJ RYiT2b9RrPKd4XGSg2d+KLGfN2zzpsyqWHbuyga86DewYaQzemcVVFtdD/0DJNGI/f4d AyCk8++uc03WbqlFw3cRo5M3pNNr0mYSOevVTgXZEqTBUx5uipi9/PIlfmV6YW1YO7Az HSeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d4si3917597oti.103.2021.05.13.10.50.51; Thu, 13 May 2021 10:51:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233146AbhEMLFJ (ORCPT + 99 others); Thu, 13 May 2021 07:05:09 -0400 Received: from mga14.intel.com ([192.55.52.115]:46125 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233141AbhEMLEU (ORCPT ); Thu, 13 May 2021 07:04:20 -0400 IronPort-SDR: VWZHYe/Mby7l9kYCgwMNb5LXK7kcpliPZRPMmi6UDGQ+N65iqCHict60jQX86NxKdviwv5Mrjc JN2CzJ8FGC0Q== X-IronPort-AV: E=McAfee;i="6200,9189,9982"; a="199604403" X-IronPort-AV: E=Sophos;i="5.82,296,1613462400"; d="scan'208";a="199604403" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2021 04:03:10 -0700 IronPort-SDR: 5ZvYE7JmNv7POUpBdNaWg80CNzrqnSkCAqnpGBTkv91x4ckpoG9eFBH3cnV4eXYRSLNvF1xQJk 47fpWqJRm5aA== X-IronPort-AV: E=Sophos;i="5.82,296,1613462400"; d="scan'208";a="623583353" Received: from adithyav-mobl.amr.corp.intel.com ([10.212.100.160]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2021 04:03:06 -0700 Message-ID: Subject: Re: [PATCH] cpufreq: intel_pstate: Force intel_pstate to load when HWP disabled in firmware From: Srinivas Pandruvada To: Giovanni Gherdovich , "Rafael J . Wysocki" , Viresh Kumar Cc: Len Brown , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 13 May 2021 04:03:02 -0700 In-Reply-To: References: <20210513075930.22657-1-ggherdovich@suse.cz> <3fdc70c267d40561bed10fc722a8223a0b161200.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2021-05-13 at 12:10 +0200, Giovanni Gherdovich wrote: > On Thu, 2021-05-13 at 02:24 -0700, Srinivas Pandruvada wrote: > > On Thu, 2021-05-13 at 09:59 +0200, Giovanni Gherdovich wrote: > > > On CPUs succeeding SKX, eg. ICELAKE_X, intel_pstate doesn't load > > > unless > > > CPUID advertises support for the HWP feature. Some OEMs, however, > > > may > > > offer > > > users the possibility to disable HWP from the BIOS config utility > > > by > > > altering the output of CPUID. > > > > Is someone providing a utility? What is the case for broken HWP? > > Yes, I know of at least one server manufacturer that ships a BIOS > config > utility where the user can disable HWP. > > On such server machine, which has an ICELAKE_X CPU, if the user > unchecks HWP > via BIOS then intel_pstate will refuse to load saying: > >     intel_pstate: CPU model not supported > > because ICELAKE_X is not in the list intel_pstate_cpu_ids (defined in > intel_pstate.c) of CPUs that intel_pstate supports when HWP is absent > from > CPUID; that list ends at SKYLAKE_X. > > An alternative approach to register intel_pstate in the case I'm > describing > would be to add ICELAKE_X (and every CPU model after that, forever?) > to the > list intel_pstate_cpu_ids. This is not nice, but unlike client server CPUs don't get released often. There is couple of years in between. > > > It is possible that some user don't want to use HWP, because there > > workloads works better without HWP. But that doesn't mean HWP is > > broken. > > That's true, a user may legitimate want to disable HWP, and we have > the > intel_pstate=no_hwp option for that. But for that option to work > CPUID must > still show that the CPU is HWP-capable; when disablement happens in > BIOS, it's > not the case. Correct. > > The wording "hwp_broken_firmware" deliberately has a negative > connotation (the > intended meaning is: "firmware is broken, regarding HWP"), carrying > the > not-so-subtle message "OEM folks, please don't do this". My > understanding is > that the preferred way to disable HWP is with intel_pstate=no_hwp, > the > firmware should stay out of it. For me "broken" means that Intel has some bug, which is not the case, even if the intention is to carry message to OEM. no_hwp is for disabling HWP even if the HWP is supported. The problem is that if we override the supported CPU list using some kernel command line, some users may crash the system running on some old hardware where some of the MSRs we rely are not present. We don't read MSR in failsafe mode, so they will fault. We are checking some MSRs but not all. Also what will be default struct pstate_funcs *)id- >driver_data if the cpu model doesn't match. I think better to add CPU model instead. We did that for SKX on user requests. Thanks, Srinivas > > I hope this clarifies the problem (there is an ICELAKE_X somewhere > out there > that can't load intel_pstate, which is not nice) and the intention > (discouraging disablement of HWP via firmware). > > > Giovanni >