Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Mi, Dapeng1" <dapeng1.mi@intel.com>
To:     "Christopherson,, Sean" <seanjc@google.com>
CC:     "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>
Subject: RE: [PATCH] KVM: x86: disable halt polling when powersave governor is
 used
Thread-Topic: [PATCH] KVM: x86: disable halt polling when powersave governor
 is used
Thread-Index: AQHYyNSFRsRhvKGUt0S7LgkC+L5J3K4DWToAgADh46CAG1uagIAgTX6g
Date:   Tue, 15 Nov 2022 06:25:24 +0000
Message-ID: <PH0PR11MB48245F82B9F5352878FD84B5CD049@PH0PR11MB4824.namprd11.prod.outlook.com>
References: <20220915073121.1038840-1-dapeng1.mi@intel.com>
 <Y0BnKIW+7sqJbTyY@google.com>
 <PH0PR11MB48240C29F1DEBC79EA933285CD5E9@PH0PR11MB4824.namprd11.prod.outlook.com>
 <Y1gXseyl0f3IUnDh@google.com>
In-Reply-To: <Y1gXseyl0f3IUnDh@google.com>
Accept-Language: en-US
Content-Language: en-US
dlp-reaction: no-action
dlp-version: 11.6.500.17
dlp-product: dlpe-windows
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?aN8b7m1aFUwS4LzT2MV1ABA3FZ8NaZsgtEnUM/br5HFEQ/UaXZ4ztfhx/bYs?=
 =?us-ascii?Q?0O+MwCxQMi75V71RI8wI1BM4aejDR67AlO3JJkhoTvX50shCxw/ZtoJ+OaGI?=
 =?us-ascii?Q?FirzVmaFtx/84rSMYw8gFfj1IwCYWsHNK8UJbpJ8K9CTo3O/uO/1UjjX4VeH?=
 =?us-ascii?Q?q40TTh+Sz0jSYYEjFDEbYtdM8hZhKKSdRfNhOU7OTbgb83VIYJbRPBRsRzxA?=
 =?us-ascii?Q?Zq8DceDcO3iUS42wuIxFc2aI4b2OqJf/xEfk9u4Ig+ictkJAGLOKNnztS3tB?=
 =?us-ascii?Q?gMEnBOgP6lp5aTj0TqTedPqNn4gjzhA9xCeTomyU8JGtltGSdS4Z/BG3752F?=
 =?us-ascii?Q?CJHJMRPUJ4CbnUfbmJHG9cP7PwylGKLzSNX1Rd3Ty33FxTW3i0XOtKwqKgXo?=
 =?us-ascii?Q?WbbRZ/nm3yLGQTwGMUZU/mBMfeRM7pMdCKV82qC0pRTT3tAb+5fNAkQYBID+?=
 =?us-ascii?Q?SNfv8SKrJHtJlzEiSj/O+TyFAKpsJ+iPVEr8nmXUle/hq2Y9rhQl/54MUDiJ?=
 =?us-ascii?Q?Bfib1HVYx8CToWEkA17giyUt0S3uWxTwiFBS1Rqb6BS6z8XEXCNDbBMaHQ7y?=
 =?us-ascii?Q?F1+vZTOF+ME3LUez+DtZz+Yl8gnnSOqpx2GRZND1WIcQoZtoQ7lMHuPM74MC?=
 =?us-ascii?Q?RPnJfHKnmGL+/qgQ6drvF/d0L9IQ4tUcqIFo24WGkOP1KDXCUzkRfCHMHZ9D?=
 =?us-ascii?Q?xBt8zllmCCC5mgrAIMMFE6WVYN/gLV0xe+F8RJv5a5G2Mi76wQTaf+8oxXDf?=
 =?us-ascii?Q?iwpG8GWhue8Qu76mA0QTQhO8mjUx3S4GYuKDbO/dG5RKYKD/IquGPPBwdblD?=
 =?us-ascii?Q?JuDRpOQ3oOzaUSNRP/CFVdj9q1vCT6iKc7ucNDtWtn0KHCnbD++yQKV6BdYo?=
 =?us-ascii?Q?sNON0OE2GipdVpYCgdmz1jzbiyKs3V43UoRrAv3ES93RB05VWeTtc5ArV2Kb?=
 =?us-ascii?Q?uDYcGtRemROOXlnsivhNeSnOT7V7o3/A6Qw7713YlQ0Kxo7ntkuFqjwd2pDj?=
 =?us-ascii?Q?ROwFyA7nQSxxBuKOrIur2Wbqb0GQNfvCbX5USEHOrzpvTo/S05mo0QaY6Jhj?=
 =?us-ascii?Q?O3TUnlqf8I/VrP4OKJHntUdSuetmSdSLW5Eb16h09Orpk3q8V2mkZVGkzrCS?=
 =?us-ascii?Q?bEFqY0/umyqMOwIgH1+sFskpon5z6xffEnhTIz1bMe6Jd5vytlxKTUmn9M/Q?=
 =?us-ascii?Q?11fAafoyUv/hej+DOFvmMfB+3jqPVFQR8WZDyTnYQET8K6n2cR9MEHrzl0Zb?=
 =?us-ascii?Q?vzZSYFXZftyYIQMLNryD/cZXZe76QJlvbVGuQQrBbnibyvmMmOGpqbEdQG9V?=
 =?us-ascii?Q?Do4F5X/aRlmfQlTk4/1zOb3G+3PnyS6AsKqdC9EsTZN7lGQigEzp2aEFAWg5?=
 =?us-ascii?Q?6tuXza0oNv5WMQ/CbPqF6EgBadFacMAwJvYkMokJbJUAXefq732wuYlD9hpQ?=
 =?us-ascii?Q?J+XzaUyaGUgBUB6oLlugkeObdsDwKxwd+zlG+e/Fh0UmM7mmlIOtV1TSC/GF?=
 =?us-ascii?Q?w+bCR3w6xg/8pSFVLtGarX1XK3tZsYsWwctexO2xPvqnoXsOHGgWhydYfYYs?=
 =?us-ascii?Q?6qsBgbCCxEjKLEv+ea7MYuVBN0MH6s/1rdip/OAS?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4824.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c5d9e427-fbe0-43ca-83e1-08dac6d22e0c
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2022 06:25:24.4194
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: D4ta8OGC702CLYZ1BP6DhG3FRQNq9pwM/U9y+S+slCQHUJkqbBL+BQ5JB0NR0rdVGr+Xoqf21TaiR9/qWTqj1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR11MB5606
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Sean Christopherson <seanjc@google.com>
> Sent: Wednesday, October 26, 2022 1:07 AM
> To: Mi, Dapeng1 <dapeng1.mi@intel.com>
> Cc: pbonzini@redhat.com; tglx@linutronix.de; mingo@redhat.com;
> dave.hansen@linux.intel.com; kvm@vger.kernel.org; linux-
> kernel@vger.kernel.org; zhenyuw@linux.intel.com
> Subject: Re: [PATCH] KVM: x86: disable halt polling when powersave
> governor is used
>=20
> On Sat, Oct 08, 2022, Mi, Dapeng1 wrote:
> > > > +				!strncmp(policy->governor->name,
> > > "powersave",
> > >
> > > KVM should not be comparing magic strings.  If the cpufreq subsystem
> > > can't get
> > > policy->policy right, then that needs to be fixed.
> >
> > Yeah, using magic strings looks a little bit strange, but this is what
> > is cpufreq doing.  Currently cpufreq mechanism supports two kinds of
> > drivers, one is the driver which has the built-in governor, like intel_=
pstate
> driver.
> > For this kind of driver, the cpufreq governor is saved in the
> > policy->policy field. The other is the traditional driver which is
> > independent with cpufreq governor and the cpufreq governor type is
> saved in the governor->name field.
> > For the second kind of cpufreq driver, the policy->policy field is
> > meaningless and we have to read the governor name.
>=20
> That doesn't mean it's ok to bleed those internal details into KVM.  I wo=
uld
> much rather cpufreq provide a helper to get the effective policy, e.g.
>=20
>   unsigned int cpufreq_cpu_get_policy(unsigned int cpu)
>   {
> 	struct cpufreq_policy *policy =3D cpufreq_cpu_get(cpu);
> 	unsigned int pol;
>=20
> 	if (!policy)
> 		return CPUFREQ_POLICY_UNKNOWN;
>=20
> 	pol =3D policy->policy
> 	if (pol =3D=3D CPUFREQ_POLICY_UNKNOWN && policy->governor)
> 		pol =3D cpufreq_parse_policy(policy->governor->name);
>=20
> 	cpufreq_cpu_put(policy);
>   }

Thanks Sean for reviewing. Would do in next version.