All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1.1 6/6] x86/apic: Convert the TSC deadline errata table to X86_MATCH_*()
Date: Fri, 18 Jul 2025 16:06:13 +0200	[thread overview]
Message-ID: <44b890e3-56a4-48da-a5b0-2aae87dc2f77@suse.com> (raw)
In-Reply-To: <772fd747-199c-4635-9f35-91468b0d12e9@citrix.com>

On 18.07.2025 12:55, Andrew Cooper wrote:
> On 18/07/2025 11:23 am, Andrew Cooper wrote:
>> On 18/07/2025 11:19 am, Jan Beulich wrote:
>>> On 18.07.2025 12:07, Andrew Cooper wrote:
>>>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>>>> helper to match a specific stepping, and use it to rework deadline_match[].
>>>>
>>>> Notably this removes the overloading of driver_data possibly being a function
>>>> pointer, and removes the latent bug where the target functions are missing
>>>> ENDBR instructions owing to the lack of the cf_check attribute.
>>>>
>>>> No functional change.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> Thanks.
> 
> Actually, this isn't as no-functional-change as I thought.
> 
> X86_FEATURE_TSC_DEADLINE has been swapped for X86_FEATURE_ANY in the table.
> 
> check_deadline_errata() is called unconditionally, without checking for
> TSC_DEADLINE, yet the rows in the table are the CPUs for which an
> erratum is known, so they all have the feature.
> 
> It does make a difference if e.g. one were to boot with
> cpuid=no-tsc-deadline.  Previously we'd have exited early, while now
> we'll emit the warning.
> 
> We could switch back to using TSC_DEADLINE (requiring a more complicated
> X86_MATCH_*() wrapper), although a better option would be to predicate
> the call to check_deadline_errata() with a feature check, because it's a
> much more recent addition to AMD CPUs, and there's no point searching
> the errata list on CPUs which lack the feature.

To be honest in this case I'd be fine with either adjustment. Switching the
feature back is more consistent with the overall purpose of X86_MATCH_*(),
but as you say a table with every entry having the same feature named isn't
very useful to go through when the feature isn't there.

One option to keep things table based, yet still avoiding to run through
the entire table, would be to allow for a "negative" entry (which here
would simply be placed first in the table).

Jan


  reply	other threads:[~2025-07-18 14:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16 17:31 [PATCH 0/6] x86: Convert x86_cpu_id to VFM Andrew Cooper
2025-07-16 17:31 ` [PATCH 1/6] x86: Sort headers Andrew Cooper
2025-07-17  7:10   ` Jan Beulich
2025-07-16 17:31 ` [PATCH 2/6] x86: Break struct x86_cpu_id out of processor.h Andrew Cooper
2025-07-17  7:23   ` Jan Beulich
2025-07-17 17:33     ` Andrew Cooper
2025-07-16 17:31 ` [PATCH 3/6] x86/match-cpu: Introduce X86_MATCH_VFM() and convert intel_idle_ids[] Andrew Cooper
2025-07-17  7:35   ` Jan Beulich
2025-07-17 17:39     ` Andrew Cooper
2025-07-18  5:38       ` Jan Beulich
2025-07-16 17:31 ` [PATCH 4/6] x86: Convert users of INTEL_FAM6_MODEL() to X86_MATCH_VFM() Andrew Cooper
2025-07-17  7:44   ` Jan Beulich
2025-07-17 17:57     ` Andrew Cooper
2025-07-18  5:40       ` Jan Beulich
2025-07-16 17:31 ` [PATCH 5/6] x86/match-cpu: Support matching on steppings Andrew Cooper
2025-07-17  8:11   ` Jan Beulich
2025-07-17 19:39     ` Andrew Cooper
2025-07-18  5:53       ` Jan Beulich
2025-07-18 10:29         ` Andrew Cooper
2025-07-18 13:28           ` Jan Beulich
2025-07-18 13:48             ` Andrew Cooper
2025-07-16 17:31 ` [PATCH 6/6] x86/apic: Convert the TSC deadline errata table to X86_MATCH_*() Andrew Cooper
2025-07-17  8:26   ` Jan Beulich
2025-07-17  9:02     ` Andrew Cooper
2025-07-17  9:33       ` Jan Beulich
2025-07-17 19:40         ` Andrew Cooper
2025-07-17  8:31   ` Jan Beulich
2025-07-17 19:45     ` Andrew Cooper
2025-07-18 10:07   ` [PATCH v1.1 " Andrew Cooper
2025-07-18 10:19     ` Jan Beulich
2025-07-18 10:23       ` Andrew Cooper
2025-07-18 10:55         ` Andrew Cooper
2025-07-18 14:06           ` Jan Beulich [this message]
2025-07-18 14:10             ` Andrew Cooper
2025-07-18 14:15         ` Jan Beulich

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=44b890e3-56a4-48da-a5b0-2aae87dc2f77@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.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.