[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 8/8] x86/cpufreq: use host CPU policy in HWP driver
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Tue, 18 Nov 2025 15:25:24 -0500
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BIb/armPiwKL08gh7vN4UjU1LnktCJ3ZTzj4hT54DQ4=; b=FUbrTDCjCn7AOGeLfTWmq23YVeJkRPlm0vafmiElpB5S63kmCymtKMsgIdh525RZ8WcSNwlGImfTD/rZlpNBE+KJHkA8s1jgc6nn4uLR21PT2FXu3lKB4r/zFhlVB7iOnB1KDsJ+9GCzyyzOmrjIK3fo0EmWbH7A8Ewaqj3MRN3wFYUaHZ6yHE2sVjWj/ZOFJO6tgjnzFmpj9Zq1P/78UVXLMfXkXneCrfQHMo/RaUaE+5/a51rnPXVE2gM0zDUvYb1jKleomo/x63lcnmvLqm/GJ0obwpo+h9OHqOKV1EgkSq1KLWdRc+K62BjRC4Z3GaoDw+ij0hnTn3ub4N9GBA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lE3W0iBIKjAUEnGrTi+2YZdfDu2aMbizsFKpdK7XxRv+A0GC1U2Q2Y4VzyaqjHEtNfreg4vsmDrJJ4F6CVbJdNVKhRnjclea4Jc/ZpcNsNFcdDD+uEVtfjPJv+uVBXZOTbmnAcummhKU/Ud/E98Nfl8tF2S9BQibxUHhbNc4zpj34aCgeYtJwe4G/XcnM3qx8Pcf2isKDmwDVa292ovc4aVVmMfmJQDwTCwdM4N44SGrUEbBwTiotyizvdc5rG+g0pnh22FOodgo+a5jIiOWXV4s4zir17lh30Gph+nxefsyPOQYMbkme2LexuSlg1pk01kXRYvmj6+DA9oLUlNsxQ==
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 18 Nov 2025 20:25:40 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2025-11-18 15:04, Andrew Cooper wrote:
On 18/11/2025 3:09 pm, Jan Beulich wrote:
--- a/xen/arch/x86/acpi/cpufreq/hwp.c
+++ b/xen/arch/x86/acpi/cpufreq/hwp.c
@@ -183,29 +178,25 @@ static bool __init hwp_available(void)
return false;
- if ( !(eax & CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE) )
+ if ( !host_cpu_policy.basic.pm.hwp_epp )
{
hwp_verbose("disabled: No energy/performance preference available");
return false;
}
- feature_hwp_notification = eax & CPUID6_EAX_HWP_NOTIFICATION;
- feature_hwp_activity_window = eax & CPUID6_EAX_HWP_ACTIVITY_WINDOW;
- feature_hdc = eax & CPUID6_EAX_HDC;
+ feature_hdc = host_cpu_policy.basic.pm.hdc;
Looking at how feature_hdc is used, I think it should be the bit within
the host policy, rather than a separate boolean.
The host policy "is" what Xen is using, so if the HWP code decides it
doesn't like HDC, then that does want reflecting.
Unrelated to this patch, but as I've been looking at the code. What
happens when hwp_init_msrs() fails on an AP? I can't see anything which
unwinds the initialised HDC state on the prior CPUs...
Assuming symmetry, it'd fail on the BSP and never get to an AP. Yes, I
didn't consider unwinding.
@@ -365,7 +357,7 @@ static void cf_check hwp_init_msrs(void
}
/* Ensure we don't generate interrupts */
- if ( feature_hwp_notification )
+ if ( host_cpu_policy.basic.pm.hwp_notification )
wrmsr_safe(MSR_HWP_INTERRUPT, 0);
Again, unrelated to the patch, but why is this a wrmsr_safe() ?
It seemed safer ;)
If the feature is enumerated, the MSR had better work.
Yes, but I wasn't sure how much to trust it. I only tested with 2
processor models, so I wanted to be safer. IIRC, I saw a #GP or two
during development. Those might have been from writing a reserved bit
and fixed during development.
Given my small testing size, I wanted to keep it safe and not take down Xen.
Regards,
Jason
|
