linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Len Brown <lenb@kernel.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-pm@vger.kernel.org, Robin Jarry <rjarry@redhat.com>,
	Joe Mario <jmario@redhat.com>
Subject: Re: [PATCH v2 1/5] x86/speculation: Provide a debugfs file to dump SPEC_CTRL MSRs
Date: Wed, 21 Jun 2023 09:47:37 -0400	[thread overview]
Message-ID: <4996d41d-3199-c4f4-ffb0-25f09709fd6c@redhat.com> (raw)
In-Reply-To: <20230621074105.GE2046280@hirez.programming.kicks-ass.net>


On 6/21/23 03:41, Peter Zijlstra wrote:
> On Tue, Jun 20, 2023 at 10:06:21AM -0400, Waiman Long wrote:
>> Sometimes it is useful to know the states the SPEC_CTRL MSRs to see what
>> mitigations are enabled at run time. Provide a new x86/spec_ctrl_msrs
>> debugfs file to dump the cached versions of the current SPEC_CTRL MSRs.
>>
> Pff, clearly I can't even read email anymore..
>
> We don't do this for any of the other MSRs, so why start now?

That is true since most of the MSRs are static. IOW, they don't change 
once they are set. The current way to read the content of the MSRs is 
via the /dev/cpu/<n>/msr files. There are user space tools to do that.

SPEC_CTRL, however, can be subjected to frequent changes especially when 
X86_FEATURE_KERNEL_IBRS is set. As a result, the current way of reading 
MSRs from /dev/cpu/<n>/msr doesn't quite work for SPEC_CTRL as the IBRS 
bit is always set due to the fact that the reading is done internally 
via an IPI in kernel space. That is the main reason that I add this 
debugfs file to get a good snapshot of the current set of cached 
SPEC_CTRL MSR values without the need to disturb what the CPUs are 
currently doing at that point in time.

This patch is not central to the main purpose of this patch series, but 
it does enable me to quickly verify the other patches are working 
correctly. I can take it out if people don't think it is a good idea.

Cheers,
Longman


  parent reply	other threads:[~2023-06-21 13:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 14:06 [PATCH v2 0/5] x86/speculation: Disable IBRS when idle Waiman Long
2023-06-20 14:06 ` [PATCH v2 1/5] x86/speculation: Provide a debugfs file to dump SPEC_CTRL MSRs Waiman Long
2023-06-21  7:41   ` Peter Zijlstra
2023-06-21  8:24     ` Borislav Petkov
2023-06-21 14:02       ` Waiman Long
2023-06-21 13:47     ` Waiman Long [this message]
2023-06-20 14:06 ` [PATCH v2 2/5] x86/idle: Disable IBRS when cpu is offline Waiman Long
2023-06-21  7:23   ` Peter Zijlstra
2023-06-21 13:59     ` Waiman Long
2023-06-21 14:36       ` Peter Zijlstra
2023-06-21 14:44         ` Waiman Long
2023-06-21 14:48           ` Peter Zijlstra
2023-06-21 14:51             ` Waiman Long
2023-06-21 14:54               ` Peter Zijlstra
2023-06-21 15:42                 ` Waiman Long
2023-06-20 14:06 ` [PATCH v2 3/5] intel_idle: Sync up the SPEC_CTRL MSR value to x86_spec_ctrl_current Waiman Long
2023-06-21  7:38   ` Peter Zijlstra
2023-06-20 14:06 ` [PATCH v2 4/5] intel_idle: Add no_ibrs module parameter to force disable IBRS Waiman Long
2023-06-21  7:30   ` Peter Zijlstra
2023-06-20 14:06 ` [PATCH v2 5/5] x86/idle: Disable IBRS entering mwait idle and enable it on wakeup Waiman Long
2023-06-21  7:32   ` Peter Zijlstra
2023-06-21 14:05     ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4996d41d-3199-c4f4-ffb0-25f09709fd6c@redhat.com \
    --to=longman@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jmario@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rjarry@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).