Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7394355rwb; Tue, 15 Nov 2022 11:35:22 -0800 (PST) X-Google-Smtp-Source: AA0mqf4fORokVqQ4Lo2AevGPf/X3/cVS7ulOckgEVC7gyGgsRl6fPykl7OMD0jPjnZmc2vKbfJA4 X-Received: by 2002:a17:906:f916:b0:7ae:ea4:583c with SMTP id lc22-20020a170906f91600b007ae0ea4583cmr15133811ejb.587.1668540922568; Tue, 15 Nov 2022 11:35:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668540922; cv=none; d=google.com; s=arc-20160816; b=vgl1Yg8C+5t6RiUJBevUydv/lyyis85affiwB8Is6RWNgBXU9pFMSNU7LwuvjHS+Pm M342rHMGVfUxiSx7EsC/WJRs12wa63dzlZymmG8kyOiMpEUUnIFNN5EEyjhy/E85W3nJ jWLHAm9sskD+3KIInVFjBI0ej/OQS7zU+CJdoMeslz7r40owq/zy8pRmqRxyIJ1W3qzd cgquJEYXMuim6+ObHWKreAayYD5JTnNdTxqHTvX04949y2BrfyzCjlrehBWgd8fAw5t4 YKtdWkiLvcaLDpKcjhzekrm4Gdd3ubuSl99krqbw3yzydzkZ12t/vj01e9wISjAeEeaA UhCQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=SmkoVgJy1qNOFL48huQShMhS/NyhKnwbz0sXSlytyO4=; b=zApcBetFFQOR9vKmmwbg/so6xzP8YXB5k0otz7AZEUFc+y/aU8Bsy0miycFdmOwcm0 gCMExRwaxajNMV3j5znA9y5aN45EkHN2lbO3XZdh0Fv8xhIH4TcUYA9A0diynmYo38uS u/DTaA076GnRwjhE5/bhfUdWjmHYiubGMAeq/bVVIxxeT9fTSD3n9TjeG4X+rdKv/M40 j09pGU2mclnATg4BB9OWn+qJzdefTEHzsLVS5IVqGdlnMMAz5p97Gcf7ynVHzurwuwTV CrGU3RItgMQK8SD6OIoJAh+64ohajOWBWmecfrqp0MyeGWpPEOzkFMzQ0PwIqrdYfg+J ijBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Lkp3BmlR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i22-20020a1709061cd600b007ae24f28400si10039585ejh.247.2022.11.15.11.34.58; Tue, 15 Nov 2022 11:35:22 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Lkp3BmlR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbiKOTR2 (ORCPT + 90 others); Tue, 15 Nov 2022 14:17:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230216AbiKOTRR (ORCPT ); Tue, 15 Nov 2022 14:17:17 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B2FF12606; Tue, 15 Nov 2022 11:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668539836; x=1700075836; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DHaRmLRkLBJINbjYiux9rmh9GmvZL3p2PYtSTdCo3wo=; b=Lkp3BmlRKujXFarp1j5wtaz6RJS4Ro27raRlu4ChbpTP72CJvFom+VAZ th0eJHmjkU1WDsGtZB7Ntg8LSBxExUehXC8HPRQHWbWc2OMrj+/KQZdKt Mnw9/sdSV0NWybAxlfqUxLzwdc0EnRzcUZkQO1a+D8Q1eUErODvkmBx22 LtxbcgQ/GxdW4ZxJrH79nCwqec9PcFBq6SfHYQVmzQ8OEC/BZ/bigpVEk j06wKoQncWhfR9qkJlIOf0nvzLw3h1Xl/Wfa4JcwwqjvRCgY99tjP6Abk U4InfinkAADRITr09J0alI6s23fFGWwZ6LlgFBgvpsg1UGo8HYl/MPww6 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10532"; a="312349974" X-IronPort-AV: E=Sophos;i="5.96,166,1665471600"; d="scan'208";a="312349974" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Nov 2022 11:17:15 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10532"; a="616872701" X-IronPort-AV: E=Sophos;i="5.96,166,1665471600"; d="scan'208";a="616872701" Received: from slmckinn-mobl.amr.corp.intel.com (HELO guptapa-desk.intel.com) ([10.255.231.2]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Nov 2022 11:17:15 -0800 From: Pawan Gupta To: Andrew Cooper , thomas.lendacky@amd.com, "H. Peter Anvin" , hdegoede@redhat.com, Ingo Molnar , "Rafael J. Wysocki" , Thomas Gleixner , x86@kernel.org, Pavel Machek , Dave Hansen , David.Kaplan@amd.com, Borislav Petkov Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Daniel Sneddon , antonio.gomez.iglesias@linux.intel.com Subject: [PATCH v3 2/2] x86/pm: Add enumeration check before spec MSRs save/restore setup Date: Tue, 15 Nov 2022 11:17:06 -0800 Message-Id: X-Mailer: git-send-email 2.37.3 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,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: X-Mailing-List: linux-kernel@vger.kernel.org pm_save_spec_msr() keeps a list of all the MSRs which _might_ need to be saved and restored at hibernate and resume. However, it has zero awareness of CPU support for these MSRs. It mostly works by unconditionally attempting to manipulate these MSRs and relying on rdmsrl_safe() being able to handle a #GP on CPUs where the support is unavailable. However, it's possible for reads (RDMSR) to be supported for a given MSR while writes (WRMSR) are not. In this case, msr_build_context() sees a successful read (RDMSR) and marks the MSR as 'valid'. Then, later, a write (WRMSR) fails, producing a nasty (but harmless) error message. This causes restore_processor_state() to try and restore it, but writing this MSR is not allowed on the Intel Atom N2600 leading to: unchecked MSR access error: WRMSR to 0x122 (tried to write 0x0000000000000002) \ at rIP: 0xffffffff8b07a574 (native_write_msr+0x4/0x20) Call Trace: restore_processor_state x86_acpi_suspend_lowlevel acpi_suspend_enter suspend_devices_and_enter pm_suspend.cold state_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 ? do_syscall_64 ? up_read ? lock_is_held_type ? asm_exc_page_fault ? lockdep_hardirqs_on entry_SYSCALL_64_after_hwframe To fix this, add the corresponding X86_FEATURE bit for each MSR. Avoid trying to manipulate the MSR when the feature bit is clear. This required adding a X86_FEATURE bit for MSRs that do not have one already, but it's a small price to pay. Fixes: 73924ec4d560 ("x86/pm: Save the MSR validity status at context setup") Reported-by: Hans de Goede Signed-off-by: Pawan Gupta Cc: stable@kernel.org --- arch/x86/power/cpu.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c index 4cd39f304e20..11a7e28f8985 100644 --- a/arch/x86/power/cpu.c +++ b/arch/x86/power/cpu.c @@ -511,18 +511,27 @@ static int pm_cpu_check(const struct x86_cpu_id *c) return ret; } +struct msr_enumeration { + u32 msr_no; + u32 feature; +}; + static void pm_save_spec_msr(void) { - u32 spec_msr_id[] = { - MSR_IA32_SPEC_CTRL, - MSR_IA32_TSX_CTRL, - MSR_TSX_FORCE_ABORT, - MSR_IA32_MCU_OPT_CTRL, - MSR_AMD64_LS_CFG, - MSR_AMD64_DE_CFG, + struct msr_enumeration msr_enum[] = { + {MSR_IA32_SPEC_CTRL, X86_FEATURE_MSR_SPEC_CTRL}, + {MSR_IA32_TSX_CTRL, X86_FEATURE_MSR_TSX_CTRL}, + {MSR_TSX_FORCE_ABORT, X86_FEATURE_TSX_FORCE_ABORT}, + {MSR_IA32_MCU_OPT_CTRL, X86_FEATURE_SRBDS_CTRL}, + {MSR_AMD64_LS_CFG, X86_FEATURE_LS_CFG_SSBD}, + {MSR_AMD64_DE_CFG, X86_FEATURE_LFENCE_RDTSC}, }; + int i; - msr_build_context(spec_msr_id, ARRAY_SIZE(spec_msr_id)); + for (i = 0; i < ARRAY_SIZE(msr_enum); i++) { + if (boot_cpu_has(msr_enum[i].feature)) + msr_build_context(&msr_enum[i].msr_no, 1); + } } static int pm_check_save_msr(void) -- 2.37.3