From nobody Sun May 5 03:23:36 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1611760041; cv=none; d=zohomail.com; s=zohoarc; b=mOoos2qhfmwMrj3T7SbF/Mck61SJYkoc6DbnqSKCIdhX2g5kj7hb09rD4JfYetNLIms487qM/4D4T0+jztAlXJ/YcREPlBZai6/qTozgaLkCKsl+AKfRdqPVnp9ezHB76Q3QwigxmmEb2nG1nV8IjJtL3QRAq5++YhlFESXwyEo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1611760041; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=5MWgf3NT9n7b4T6UhOpwGHv0BUBDVYIplb2zQXcQ6bc=; b=fpSuOSRFdYsdTNFtk1x3Zz1PkLFRAOTSB/QEtjvL459hxDBpoA+0nZlVbRwALYdWExCGo/J2wbJ/aTwUIQPeLedqgwXm+jiR/5mdZPE+EYIAathkhe8sfBcru6gIPaW5Ri4MkHMZV3T50rJKuoQKsn4wzAVxnR/NpYMPZQWI5ik= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 161176004161222.205202063488855; Wed, 27 Jan 2021 07:07:21 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.76134.137248 (Exim 4.92) (envelope-from ) id 1l4mP6-0007Bl-Ly; Wed, 27 Jan 2021 15:06:44 +0000 Received: by outflank-mailman (output) from mailman id 76134.137248; Wed, 27 Jan 2021 15:06:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4mP6-0007Be-IT; Wed, 27 Jan 2021 15:06:44 +0000 Received: by outflank-mailman (input) for mailman id 76134; Wed, 27 Jan 2021 15:06:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4mP5-0007BZ-8N for xen-devel@lists.xenproject.org; Wed, 27 Jan 2021 15:06:43 +0000 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 797b74f3-723d-4349-a160-f92233ece703; Wed, 27 Jan 2021 15:06:42 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 797b74f3-723d-4349-a160-f92233ece703 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1611760001; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Urw+0M2RN5OXbE1CP5wlKFIaC/7H3qvdf/pd1my9Rkw=; b=RPX+7ydV4T0IZl5CG5lnWhll03jyZftloKX8u0lVb9Sp7XhByfXIvKuO PxoIxs5I0cIvkKHrNyJTsn3A3+cM0sxAWaqoCYcoBYqNLopQZSuJRRUIa kSoHr12UYrL1YiuYOpYnn7XYboaShhDL7oRcn8uEUcvL8ByqaCZNoq3Sj k=; Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: W+gU9OUiDWb2Ww5VsZyQ22ioZjuhkvFbvoE+zpbcJGE7x+HjjOAQqwTqUY+sdoHqiGUN3pt7Xt ma43YpWQJfsdjZ5jwrDtAPpQsDItelbFBMMZ6TKcwqCL7l1fHJcPSg/SFJuD047D0A1v85XCxN BANC1xWWKwMfnWWU1UH+8KkQr+3X9Qg/fjlola9i8t8cjzn8UAIYFlKI+VegT/X2S0QBKqTQxU o6Jp2NMOpF4bvvoSMo8HnGvXQ0nxbFKrDhLQs5t9ye2h6aGPWJ+qqrntJrjEhbJxb6kZtx8Lh3 H9I= X-SBRS: 5.2 X-MesageID: 37285657 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.79,379,1602561600"; d="scan'208";a="37285657" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu , Aaron Janse , Jason Andryuk , Ondrej Balaz , "Tamas K Lengyel" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v2] x86/timer: Fix boot on Intel systems using ITSSPRC static PIT clock gating Date: Wed, 27 Jan 2021 15:06:15 +0000 Message-ID: <20210127150615.641-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) Recent Intel client devices have disabled the legacy PIT for powersaving reasons, breaking compatibility with a traditional IBM PC. Xen depends on a legacy timer interrupt to check that the IO-APIC/PIC routing is configured correctly, and fails to boot with: (XEN) ******************************* (XEN) Panic on CPU 0: (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=3Ddebug and= send report. Then try booting with the `noapic` option (XEN) ******************************* While this setting can be undone by Xen, the details of how to differ by chipset, and would be very short sighted for battery based devices. See bi= t 2 "8254 Static Clock Gating Enable" in: https://edc.intel.com/content/www/us/en/design/products-and-solutions/pro= cessors-and-chipsets/comet-lake-u/intel-400-series-chipset-on-package-platf= orm-controller-hub-register-database/itss-power-reduction-control-itssprc-o= ffset-3300/ All impacted systems have an HPET, but there is no indication of the absence of PIT functionality, nor a suitable way to probe for its absence. As a sh= ort term fix, reconfigure the HPET into legacy replacement mode. A better longterm fix would be to avoid the reliance on the timer interrupt entirely. Signed-off-by: Andrew Cooper Tested-by: Jason Andryuk Acked-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu CC: Aaron Janse CC: Jason Andryuk CC: Ondrej Balaz CC: Tamas K Lengyel CC: Marek Marczykowski-G=C3=B3recki v2: * Fix build - misplaced bracket. * Tweak description of SETVAL. Slightly RFC. On older platforms this does generate some spurious PIC interrupts during boot, but they're benign. I was hoping to have time to f= ix those too, but I'm getting an increasing number of requests to post this patch. Other followup actions: * Overhaul our setup logic. Large quantities of it is legacy for pre-64bit systems, and not applicable to Xen these days. * Have Xen turn the PIT off when it isn't being used as the timesource. I= ts a waste of time servicing useless interrupts. * Make `clocksource=3Dpit` not enter an infinite loop on these systems * Drop all references to `noapic`. These days, the only thing it will ever do is make a bad situation worse. --- xen/arch/x86/hpet.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++= +++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c index e6fab8acd8..876c5e4769 100644 --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -758,7 +758,7 @@ static u32 *hpet_boot_cfg; u64 __init hpet_setup(void) { static u64 __initdata hpet_rate; - u32 hpet_id, hpet_period; + unsigned int hpet_id, hpet_period, hpet_cfg; unsigned int last, rem; =20 if ( hpet_rate ) @@ -793,6 +793,68 @@ u64 __init hpet_setup(void) if ( (rem * 2) > hpet_period ) hpet_rate++; =20 + /* + * Intel chipsets from Skylake/ApolloLake onwards can statically clock + * gate the 8259 PIT. This option is enabled by default in slightly l= ater + * systems, as turning the PIT off is a prerequisite to entering the C= 11 + * power saving state. + * + * Xen currently depends on the legacy timer interrupt being active wh= ile + * IRQ routing is configured. + * + * Reconfigure the HPET into legacy mode to re-establish the timer + * interrupt. + */ + if ( hpet_id & HPET_ID_LEGSUP && + !((hpet_cfg =3D hpet_read32(HPET_CFG)) & HPET_CFG_LEGACY) ) + { + unsigned int c0_cfg, ticks, count; + + /* Stop the main counter. */ + hpet_write32(hpet_cfg & ~HPET_CFG_ENABLE, HPET_CFG); + + /* Reconfigure channel 0 to be 32bit periodic. */ + c0_cfg =3D hpet_read32(HPET_Tn_CFG(0)); + c0_cfg |=3D (HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL | + HPET_TN_32BIT); + hpet_write32(c0_cfg, HPET_Tn_CFG(0)); + + /* + * The exact period doesn't have to match a legacy PIT. All we ne= ed + * is an interrupt queued up via the IO-APIC to check routing. + * + * Use HZ as the frequency. + */ + ticks =3D ((SECONDS(1) / HZ) * div_sc(hpet_rate, SECONDS(1), 32)) = >> 32; + + count =3D hpet_read32(HPET_COUNTER); + + /* + * HPET_TN_SETVAL above is atrociously documented in the spec. + * + * Periodic HPET channels have a main comparator register, and + * separate accumulator register. Each time an interrupt is + * generated, the accumulator register is re-added to the comparat= or + * set up the new period. + * + * Normally, writes to the CMP register update both registers. + * However, under these semantics, it is impossible to set up a + * periodic timer correctly without the main HPET counter being at= 0. + * + * Instead, HPET_TN_SETVAL is a self-clearing control bit which we= can + * use for periodic timers to mean that the second write to CMP + * updates the accumulator only, and not the absolute comparator + * value. + * + * This lets us set a period when the main counter isn't at 0. + */ + hpet_write32(count + ticks, HPET_Tn_CMP(0)); + hpet_write32(ticks, HPET_Tn_CMP(0)); + + /* Restart the main counter, and legacy mode. */ + hpet_write32(hpet_cfg | HPET_CFG_ENABLE | HPET_CFG_LEGACY, HPET_CF= G); + } + return hpet_rate; } =20 --=20 2.11.0