All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
Date: Fri, 29 Mar 2024 12:40:07 +0100	[thread overview]
Message-ID: <20240329114007.GAZgaolwSFtjHStiuL@fat_crate.local> (raw)
In-Reply-To: <SJ1PR11MB6083D8BB65748452B204ED8AFC3B2@SJ1PR11MB6083.namprd11.prod.outlook.com>

On Thu, Mar 28, 2024 at 06:32:35PM +0000, Luck, Tony wrote:
> I don't think the format is really that big an issue. Including stepping in the
> format adds complexity to a thousand places these checks are made while
> only being useful in a few dozen.

I've figured out what the problem is with steppings - ranges. If you
have a range of steppings which all belong to the same model, then you
have to complicate the checks by either masking out the stepping or use
the X86_STEPPING_ANY thing which forces you to use x86_match_cpu()
instead of a simple integer comparison.

And you should talk to your folks what their plan is for the new
families because if they do a range of model numbers which all belong to
the same CPU model like AMD does, then your simple comparison scheme
goes out the window because it can't really deal with ranges.

Because from looking at your set, I don't see a slick way to check
whether a concrete f/m/s tuple belongs to a range without involved
checking.

For example, models:

                case 0x30 ... 0x4f:
                case 0x60 ... 0x7f:
                case 0x90 ... 0x91:
                case 0xa0 ... 0xaf:

are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had
a patch like that at some point but it didn't go in. But even if I did
that, I'd still need to do x86_match_cpu() instead of the current
X86_FEATURE_ZEN* checks we're doing.

So I don't think I can switch AMD to use that. It looks like the 'V' in
"VFM" could just as well turn into "I".

:-)

I'd say.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  parent reply	other threads:[~2024-03-29 11:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 16:37 [PATCH 00/74] New Intel CPUID families Tony Luck
2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck
2024-03-28 16:48   ` Borislav Petkov
2024-03-28 16:52     ` Borislav Petkov
2024-03-28 17:00       ` Luck, Tony
2024-03-28 17:12         ` Borislav Petkov
2024-03-28 18:32           ` Luck, Tony
2024-03-28 20:52             ` Luck, Tony
2024-03-29 11:40             ` Borislav Petkov [this message]
2024-03-29 16:46               ` Tony Luck
2024-03-29 17:23                 ` Borislav Petkov
2024-04-01 18:18               ` Tony Luck
2024-04-07 10:54                 ` Borislav Petkov
2024-04-08 16:20                   ` Luck, Tony
2024-04-09  8:22                     ` Borislav Petkov
2024-04-16 18:16                       ` Tony Luck
2024-04-16 18:23                         ` Borislav Petkov
2024-04-16 18:37                           ` Luck, Tony
2024-04-16 19:58                             ` Borislav Petkov
2024-04-16 21:45                               ` Luck, Tony
2024-04-17 19:02                                 ` Sean Christopherson
2024-04-17 19:42                                   ` Borislav Petkov
2024-04-18  1:47                                     ` Luck, Tony
2024-03-28 16:56     ` Luck, Tony
2024-03-28 17:06       ` Borislav Petkov
2024-04-01 18:23   ` [PATCH v2 " Tony Luck
2024-04-09 12:46     ` Thomas Gleixner
2024-03-28 16:37 ` [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values Tony Luck
2024-04-01 18:24   ` [PATCH v2 " Tony Luck
2024-04-09 12:47     ` Thomas Gleixner
2024-03-28 16:37 ` [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h Tony Luck
2024-04-09 12:48   ` Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2024-03-28 16:26 [PATCH 00/74] New Intel CPUID families Tony Luck
2024-03-28 16:26 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck

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=20240329114007.GAZgaolwSFtjHStiuL@fat_crate.local \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --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 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.