From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E524DC433FE for ; Fri, 18 Nov 2022 18:29:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242817AbiKRS3p (ORCPT ); Fri, 18 Nov 2022 13:29:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242772AbiKRS3R (ORCPT ); Fri, 18 Nov 2022 13:29:17 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4879976EF; Fri, 18 Nov 2022 10:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668796075; x=1700332075; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mqjewkRpUIDxGJT0uKLmbhczG2Cqq27+ixwZGMtIhdE=; b=Gf5GJ0D7NS5WqrS89mlV82ZTta2DMF22TE1aiIVwS0R4MQNoLOKUd9NX wnQcxC+tdAfP+mnhaul9QbpRqxcbVsPiaVh57Hc+IjOa7EP2qxJDvJdAH 6CIE6QZlcfcItAFxatlk/qdkTB1EVBIGsbJ4ouNfxSasykaccx7qElAwk QpkexkXUPmybPn2a4KsVHnHA2m9fHLJhR/Zu7uvdfaM9LhFuVCxLc8Mwn eFxjmwJ6h81yd9YDUxcGNhIFJKPQH+QvwirqYx3TAVGVEH46+60uq4f23 UoBsP7rY7R9EplJluKHTpXu4AeSdG+n+ITA5YauMB/gIBNtiZaRqE/w0I g==; X-IronPort-AV: E=McAfee;i="6500,9779,10535"; a="315022109" X-IronPort-AV: E=Sophos;i="5.96,175,1665471600"; d="scan'208";a="315022109" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2022 10:27:55 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10535"; a="703834773" X-IronPort-AV: E=Sophos;i="5.96,175,1665471600"; d="scan'208";a="703834773" Received: from bfan1-mobl1.amr.corp.intel.com (HELO desk) ([10.209.78.213]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2022 10:27:54 -0800 Date: Fri, 18 Nov 2022 10:27:52 -0800 From: Pawan Gupta To: Dave Hansen Cc: 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 , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Daniel Sneddon , antonio.gomez.iglesias@linux.intel.com Subject: Re: [PATCH v3 2/2] x86/pm: Add enumeration check before spec MSRs save/restore setup Message-ID: <20221118182752.7ovqckwwle3azzrc@desk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2022 at 10:12:32AM -0800, Dave Hansen wrote: >On 11/15/22 11:17, Pawan Gupta wrote: >> 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 > >Thanks for fixing this up. The X86_FEATURE approach is a good one. The >"poking at random MSRs" always seemed a bit wonky. > >Reviewed-by: Dave Hansen Thanks.