All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v4 02/10] TAAv4 2
Date: Wed, 25 Sep 2019 17:46:00 -0700	[thread overview]
Message-ID: <20190926004559.GB16811@guptapadev.amr> (raw)
In-Reply-To: <20190925221319.5h4c3os5ptm6iaft@treble>

On Wed, Sep 25, 2019 at 05:13:19PM -0500, speck for Josh Poimboeuf wrote:
> On Fri, Sep 06, 2019 at 02:07:12PM -0700, speck for Dave Hansen wrote:
> > On 9/4/19 12:43 AM, speck for Pawan Gupta wrote:
> > > On Wed, Sep 04, 2019 at 07:54:06AM +0200, speck for Greg KH wrote:
> > >>> +static void tsx_ctrl_check_support(struct cpuinfo_x86 *c)
> > >>> +{
> > >>> +	u64 ia32_cap = 0;
> > >>> +
> > >>> +	if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
> > >>> +		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
> > >>> +
> > >>> +	if (!(ia32_cap & ARCH_CAP_TSX_CTRL_MSR))
> > >>> +		tsx_ctrl_state = TSX_CTRL_NOT_SUPPORTED;
> > >> Why isn't this if statement under the if statement above?
> > > Because we still have to set tsx_ctrl_state when cpu doesn't support
> > > X86_FEATURE_ARCH_CAPABILITIES.
> > 
> > FWIW, I struggled to read this the first time I read it, too.  It might
> > make sense to break it up like this:
> > 
> > u64 read_ia32_arch_cap(void)
> > {
> > 	u64 ia32_cap = 0;
> > 
> > 	/* Leave the MSR set to all 0's when not supported */
> > 	if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
> > 		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
> > 
> > 	return ia32_cap;
> > }
> > 
> > You could even replace the other places that we read the MSR.  They have
> > the same pattern.  Then do:
> > 
> > static void tsx_ctrl_check_support(struct cpuinfo_x86 *c)
> > {
> > 	u64 ia32_cap = read_ia32_arch_cap();
> > 
> > 	if (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)
> > 		tsx_ctrl_state = TSX_CTRL_ENABLE;
> > }
> > 
> > which takes tsx_ctrl_state out of the 'disable' mode.
> 
> I think it would be even clearer if the compile-time default were
> changed to TSX_CTRL_NOT_SUPPORTED.
> 
> Then the logic would be less confusing.  For example the reader of the
> code doesn't have to remember that ia32_cap is initialized to zero.  And
> IMO, "not supported" conceptually makes the most sense as a compile-time
> default anyway.
> 
> static void tsx_ctrl_check_support(struct cpuinfo_x86 *c)
> {
> 	u64 ia32_cap;
> 
> 	if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES)) {
> 		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
> 
> 		if (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)
> 			tsx_ctrl_state = TSX_CTRL_DISABLE;

Below is the order in which tsx_ctrl_state can be modified:
1. Compile time
2. Cmdline parsing (early_param())
3. TSX_CTRL MSR support check (tsx_ctrl_check_support())

Here we need to handle tsx=on case as well. If we set tsx_ctrl_state to
ENABLE/DISABLE in tsx_ctrl_check_support() we could override what user
asked for via cmdline. Unless we keep another copy of tsx_ctrl_state,
which might add more complexity.

I believe tsx_ctrl_check_support() should only change state to
NOT_SUPPORTED when TSX_CTRL MSR is not supported.

Thanks,
Pawan

  reply	other threads:[~2019-09-26  0:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1567543894.git.pawan.kumar.gupta@linux.intel.com>
2019-09-23 12:47 ` [MODERATED] Re: [PATCH v4 01/10] TAAv4 1 Borislav Petkov
     [not found] ` <20190904060028.GD7212@kroah.com>
     [not found]   ` <20190906072835.GD13480@guptapadev.amr>
     [not found]     ` <20190906092727.GA16843@kroah.com>
     [not found]       ` <20190910184223.GA7543@guptapadev.amr>
     [not found]         ` <20190910223334.GA21301@kroah.com>
     [not found]           ` <20190910233449.GA10041@agluck-desk2.amr.corp.intel.com>
2019-09-23 19:10             ` [MODERATED] Re: [PATCH v4 04/10] TAAv4 4 Greg KH
     [not found]           ` <20190911023223.GA8305@guptapadev.amr>
2019-09-23 19:13             ` Greg KH
2019-09-23 22:25               ` Pawan Gupta
2019-09-24  5:04                 ` Greg KH
2019-09-24 10:48                   ` Jiri Kosina
2019-09-24 13:31                     ` Greg KH
2019-09-24 13:38                       ` Jiri Kosina
2019-09-24 13:47                         ` Greg KH
2019-09-24 23:25                   ` Pawan Gupta
2019-09-27  7:01                     ` Greg KH
2019-09-25 21:10 ` [MODERATED] Re: [PATCH v4 06/10] TAAv4 6 Kanth Ghatraju
2019-09-25 21:11   ` [MODERATED] [AUTOREPLY] [AUTOREPLY] Automatic reply: " Hatle, Mark
2019-09-26  1:15   ` [MODERATED] " Pawan Gupta
     [not found] ` <20190904055711.GC7212@kroah.com>
     [not found]   ` <nycvar.YFH.7.76.1909040759580.31470@cbobk.fhfr.pm>
     [not found]     ` <20190904061155.GI7212@kroah.com>
     [not found]       ` <20190904075846.GD1321@guptapadev.amr>
     [not found]         ` <20190904084306.GA4925@kroah.com>
     [not found]           ` <20190904112758.GP3838@dhcp22.suse.cz>
2019-09-25 22:05             ` [MODERATED] Re: ***UNCHECKED*** Re: [PATCH v4 03/10] TAAv4 3 Josh Poimboeuf
2019-10-01  0:20               ` [MODERATED] " Pawan Gupta
2019-10-02 14:55                 ` Borislav Petkov
2019-10-05  5:16                   ` Pawan Gupta
2019-10-08  2:59                     ` Josh Poimboeuf
2019-10-08  6:15                       ` Pawan Gupta
2019-10-08 18:06                       ` Dave Hansen
2019-10-08 18:36                         ` [MODERATED] Re: ***UNCHECKED*** " Jiri Kosina
     [not found] ` <20190904055406.GA7212@kroah.com>
     [not found]   ` <20190904074326.GB1321@guptapadev.amr>
     [not found]     ` <bfe6f7e0-22db-ce4d-ac3a-875482b43489@intel.com>
2019-09-25 22:13       ` [MODERATED] Re: [PATCH v4 02/10] TAAv4 2 Josh Poimboeuf
2019-09-26  0:46         ` Pawan Gupta [this message]
2019-09-25 22:30 ` Josh Poimboeuf
2019-09-30 23:26   ` Pawan Gupta
2019-09-30 23:32     ` [MODERATED] [AUTOREPLY] [MODERATED] [AUTOREPLY] Automatic reply: " James, Hengameh M
     [not found] ` <5b6df5ee-a5b7-c281-de29-af6544b8abb6@intel.com>
     [not found]   ` <20190906074645.GE13480@guptapadev.amr>
2019-09-25 22:48     ` [MODERATED] Re: [PATCH v4 03/10] TAAv4 3 Josh Poimboeuf
2019-09-25 23:12       ` Dave Hansen
2019-09-25 23:22         ` Andrew Cooper
2019-09-26  1:13       ` Pawan Gupta
2019-09-26  2:34         ` Josh Poimboeuf
2019-09-26  7:15           ` Pawan Gupta
2019-09-26 13:54             ` Josh Poimboeuf
2019-09-26 17:57               ` Pawan Gupta
     [not found] ` <d6fd9ad7-79f7-aab9-db31-a9a2ca03aa10@intel.com>
     [not found]   ` <20190906080828.GF13480@guptapadev.amr>
     [not found]     ` <00170736-0d97-4a48-2141-ffba4bb67199@intel.com>
2019-09-25 22:58       ` [MODERATED] Re: [PATCH v4 04/10] TAAv4 4 Josh Poimboeuf
2019-09-26  0:48         ` Pawan Gupta
2019-09-25 23:06 ` [MODERATED] Re: [PATCH v4 06/10] TAAv4 6 Josh Poimboeuf
2019-09-30 23:00   ` Pawan Gupta
2019-10-01 18:26 ` [MODERATED] Re: [PATCH v4 05/10] TAAv4 5 Pawan Gupta

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=20190926004559.GB16811@guptapadev.amr \
    --to=pawan.kumar.gupta@linux.intel.com \
    --cc=speck@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.