All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Sandipan Das <sandipan.das@amd.com>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	x86@kernel.org, peterz@infradead.org, leitao@debian.org,
	mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	namhyung@kernel.org, irogers@google.com, adrian.hunter@intel.com,
	tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, leit@fb.com, dcostantino@meta.com,
	jhladky@redhat.com, eranian@google.com, ananth.narayan@amd.com,
	ravi.bangoria@amd.com, santosh.shukla@amd.com
Subject: Re: rom 3540f985652f41041e54ee82aa53e7dbd55739ae Mon Sep 17 00:00:00 2001
Date: Fri, 22 Sep 2023 12:03:34 +0200	[thread overview]
Message-ID: <ZQ1mdoMBJd4PCvZa@gmail.com> (raw)
In-Reply-To: <20230914140604.267672-1-sandipan.das@amd.com>


* Sandipan Das <sandipan.das@amd.com> wrote:

> Zen 4 systems running buggy microcode can hit a WARN_ON() in the PMI
> handler, as shown below, several times while perf runs. A simple
> `perf top` run is enough to render the system unusable.
> 
> WARNING: CPU: 18 PID: 20608 at arch/x86/events/amd/core.c:944 amd_pmu_v2_handle_irq+0x1be/0x2b0
> 
> This happens because the Performance Counter Global Status Register
> (PerfCntGlobalStatus) has one or more bits set which are considered
> reserved according to the "AMD64 Architecture Programmer???s Manual,
> Volume 2: System Programming, 24593". The document can be found at
> https://www.amd.com/system/files/TechDocs/24593.pdf
> 
> To make this less intrusive, warn just once if any reserved bit is set
> and prompt the user to update the microcode. Also sanitize the value to
> what the code is handling, so that the overflow events continue to be
> handled for the number of counters that are known to be sane.
> 
> Going forward, the following microcode patch levels are recommended
> for Zen 4 processors in order to avoid such issues with reserved bits.
> 
>   Family=0x19 Model=0x11 Stepping=0x01: Patch=0x0a10113e
>   Family=0x19 Model=0x11 Stepping=0x02: Patch=0x0a10123e
>   Family=0x19 Model=0xa0 Stepping=0x01: Patch=0x0aa00116
>   Family=0x19 Model=0xa0 Stepping=0x02: Patch=0x0aa00212
> 
> Commit f2eb058afc57 ("linux-firmware: Update AMD cpu microcode") from
> the linux-firmware tree has binaries that meet the minimum required
> patch levels.
> 
> Fixes: 7685665c390d ("perf/x86/amd/core: Add PerfMonV2 overflow handling")
> Reported-by: Jirka Hladky <jhladky@redhat.com>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> [sandipan: add message to prompt users to update microcode]
> [sandipan: rework commit message and call out required microcode levels]
> Signed-off-by: Sandipan Das <sandipan.das@amd.com>

> v2:
>  - Use pr_warn_once() instead of WARN_ON_ONCE() to prompt users to
>    update microcode
>  - Rework commit message and add details of minimum required microcode
>    patch levels.

1)

I don't think you ever re-sent this patch with the correct subject line.
( Or at least it's not in my mbox. )

2)

So if the fix is from Breno Leitao originally, then there should be a:

   From: Breno Leitao <leitao@debian.org>

at the beginning of the patch to make authorship clear.

You might also want to add:

  Co-developed-by: Sandipan Das <sandipan.das@amd.com>

to make your contributions clear.

Thanks,

	Ingo

  parent reply	other threads:[~2023-09-22 10:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14 14:06 rom 3540f985652f41041e54ee82aa53e7dbd55739ae Mon Sep 17 00:00:00 2001 Sandipan Das
2023-09-14 14:27 ` Sandipan Das
2023-09-22 10:03 ` Ingo Molnar [this message]
2023-09-22 10:23   ` Sandipan Das

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=ZQ1mdoMBJd4PCvZa@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ananth.narayan@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dcostantino@meta.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=jhladky@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=leit@fb.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=sandipan.das@amd.com \
    --cc=santosh.shukla@amd.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 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.