<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/x86, branch v6.18.33</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.33</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.33'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-23T11:07:20+00:00</updated>
<entry>
<title>perf/x86/intel: Disable PMI for self-reloaded ACR events</title>
<updated>2026-05-23T11:07:20+00:00</updated>
<author>
<name>Dapeng Mi</name>
<email>dapeng1.mi@linux.intel.com</email>
</author>
<published>2026-05-18T01:23:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a3c44e77f3796f62b890c8a72eb1161efd525a8b'/>
<id>urn:sha1:a3c44e77f3796f62b890c8a72eb1161efd525a8b</id>
<content type='text'>
[ Upstream commit 1271aeccc307066315b2d3b0d5af2510e27018b5 ]

On platforms with Auto Counter Reload (ACR) support, such as NVL, a
"NMI received for unknown reason 30" warning is observed when running
multiple events in a group with ACR enabled:

  $ perf record -e '{instructions/period=20000,acr_mask=0x2/u,\
    cycles/period=40000,acr_mask=0x3/u}' ./test

The warning occurs because the Performance Monitoring Interrupt (PMI)
is enabled for the self-reloaded event (the cycles event in this case).
According to the Intel SDM, the overflow bit
(IA32_PERF_GLOBAL_STATUS.PMCn_OVF) is never set for self-reloaded events.
Since the bit is not set, the perf NMI handler cannot identify the source
of the interrupt, leading to the "unknown reason" message.

Furthermore, enabling PMI for self-reloaded events is unnecessary and
can lead to extraneous records that pollute the user's requested data.

Disable the interrupt bit for all events configured with ACR self-reload.

Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Reported-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Dapeng Mi &lt;dapeng1.mi@linux.intel.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430002558.712334-4-dapeng1.mi@linux.intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/kexec: Push kjump return address even for non-kjump kexec</title>
<updated>2026-05-23T11:07:18+00:00</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw@amazon.co.uk</email>
</author>
<published>2026-04-28T20:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b0bd7a850e1f082560959707dbf57b0402071646'/>
<id>urn:sha1:b0bd7a850e1f082560959707dbf57b0402071646</id>
<content type='text'>
commit 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 upstream.

The version of purgatory code shipped by kexec-tools attempts to look above
the top of its stack to find a return address for a kjump, even in a non-kjump
kexec.

After the commit in Fixes: the word above the stack might not be there,
leading to a fault (which is at least now caught by my exception-handling code
in kexec).

That commit fixed things for the actual kjump path, but no longer
"gratuitously" pushes the unused return address to the stack in the non-kjump
path. Put that *back* in the non-kjump path, to prevent purgatory from
crashing when trying to access it.

Fixes: 2cacf7f23a02 ("x86/kexec: Fix stack and handling of re-entry point for ::preserve_context")
Reported-by: Rohan Kakulawaram &lt;rohanka@google.com&gt;
Signed-off-by: David Woodhouse &lt;dwmw@amazon.co.uk&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Acked-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Tested-by: Rohan Kakulawaram &lt;rohanka@google.com&gt;
Cc: &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/32d627134143ffd957891cb697138e839c623211.camel@infradead.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: x86: Fix Xen hypercall tracepoint argument assignment</title>
<updated>2026-05-23T11:07:16+00:00</updated>
<author>
<name>Qiang Ma</name>
<email>maqianga@uniontech.com</email>
</author>
<published>2026-05-12T01:53:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8adc988e9f2061501340697d9ef581f09891253b'/>
<id>urn:sha1:8adc988e9f2061501340697d9ef581f09891253b</id>
<content type='text'>
commit 2b72f1674e427c56e3772c5ccf785fdda2138820 upstream.

TRACE_EVENT(kvm_xen_hypercall) stores a5 in __entry-&gt;a4 instead of
__entry-&gt;a5.

That overwrites the recorded a4 argument and leaves a5 unset in the
trace entry. Fix the typo so both arguments are captured correctly.

Signed-off-by: Qiang Ma &lt;maqianga@uniontech.com&gt;
Link: https://patch.msgid.link/20260512015313.1685784-1-maqianga@uniontech.com/
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"</title>
<updated>2026-05-23T11:07:16+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2026-05-04T23:01:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a9f76de38ba32389f8c2e3bc3b7fb1d62e2f8f77'/>
<id>urn:sha1:a9f76de38ba32389f8c2e3bc3b7fb1d62e2f8f77</id>
<content type='text'>
commit db5dadb562cabb6da49959b473ed0d9645b6f2da upstream.

Some older systems don't support CPPC in the firmware and this just makes
noise for them when booting.  Drop back to debug.

This reverts commit 21fb59ab4b9767085f4fe1edbdbe3177fbb9ec97.

Fixes: 21fb59ab4b976 ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn")
Suggested-by: Kim Phillips &lt;kim.phillips@amd.com&gt;
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Tested-by: Kim Phillips &lt;kim.phillips@amd.com&gt;
Cc: All applicable &lt;stable@vger.kernel.org&gt;
Link: https://patch.msgid.link/20260504230141.484743-2-mario.limonciello@amd.com
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>x86/um: fix vDSO installation</title>
<updated>2026-05-23T11:06:57+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2026-03-18T21:03:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07410592862686ad3be4906b1fcabc253d3961d8'/>
<id>urn:sha1:07410592862686ad3be4906b1fcabc253d3961d8</id>
<content type='text'>
[ Upstream commit d1895c15fc7d90a615bc8c455feb02acaf08ef1e ]

The generic vDSO installation logic used by 'make vdso_install' requires
that $(vdso-install-y) is defined by the top-level architecture Makefile
and that it contains a path relative to the root of the tree.
For UML neither of these is satisfied.

Move the definition of $(vdso-install-y) to a place which is included by
the arch/um/Makefile and use the full relative path.

Fixes: f1c2bb8b9964 ("um: implement a x86_64 vDSO")
Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://patch.msgid.link/20260318-um-vdso-install-v1-1-26a4ca5c4210@weissschuh.net
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/um/vdso: Drop VDSO64-y from Makefile</title>
<updated>2026-05-23T11:06:57+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2025-10-13T10:40:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f548ecd2d7812a27498bcf8b0b0656b9c21567a'/>
<id>urn:sha1:0f548ecd2d7812a27498bcf8b0b0656b9c21567a</id>
<content type='text'>
[ Upstream commit 3c9b904f9033fb250db72d258bbdec791dc89405 ]

This symbol is unnecessary, remove it.

Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Link: https://patch.msgid.link/20251013-uml-vdso-cleanup-v1-4-a079c7adcc69@weissschuh.net
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Stable-dep-of: d1895c15fc7d ("x86/um: fix vDSO installation")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/vdso: Clean up remnants of VDSO32_NOTE_MASK</title>
<updated>2026-05-23T11:06:25+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>thomas.weissschuh@linutronix.de</email>
</author>
<published>2026-03-30T12:07:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5bdb8404df4a9dca83d4535496d4b1cb99fee6e'/>
<id>urn:sha1:e5bdb8404df4a9dca83d4535496d4b1cb99fee6e</id>
<content type='text'>
[ Upstream commit 6517f293b2c6774d21b6e7e26a55fae60c6ec4cf ]

VDSO32_NOTE_MASK is not used or provided anymore, remove it.

Fixes: a13f2ef168cb ("x86/xen: remove 32-bit Xen PV guest support")
Signed-off-by: Thomas Weißschuh &lt;thomas.weissschuh@linutronix.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Cc: Juergen Gross &lt;jgross@suse.com&gt;
Link: https://patch.msgid.link/20260330-vdso-x86-vdso32_note_mask-v1-1-2f5c473327bf@linutronix.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/tdx: Fix the typo in TDX_ATTR_MIGRTABLE</title>
<updated>2026-05-23T11:06:25+00:00</updated>
<author>
<name>Xiaoyao Li</name>
<email>xiaoyao.li@intel.com</email>
</author>
<published>2026-03-03T03:03:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=90e8cfcd217cb07a5c22e681be8eaa87d7c8bd92'/>
<id>urn:sha1:90e8cfcd217cb07a5c22e681be8eaa87d7c8bd92</id>
<content type='text'>
[ Upstream commit 3aecb2e7b948400354399b26f3f1653bd2c1bae0 ]

The TD scoped TDCS attributes are defined by bit positions. In the guest
side of the TDX code, the 'tdx_attributes' string array holds pretty
print names for these attributes, which are generated via macros and
defines. Today these pretty print names are only used to print the
attribute names to dmesg.

Unfortunately there is a typo in the define for the migratable bit.
Change the defines TDX_ATTR_MIGRTABLE* to TDX_ATTR_MIGRATABLE*. Update
the sole user, the tdx_attributes array, to use the fixed name.

Since these defines control the string printed to dmesg, the change is
user visible. But the risk of breakage is almost zero since it is not
exposed in any interface expected to be consumed programmatically.

Fixes: 564ea84c8c14 ("x86/tdx: Dump attributes and TD_CTLS on boot")
Signed-off-by: Xiaoyao Li &lt;xiaoyao.li@intel.com&gt;
Signed-off-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Reviewed-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reviewed-by: Kai Huang &lt;kai.huang@intel.com&gt;
Acked-by: Sean Christopherson &lt;seanjc@google.com&gt;
Link: https://patch.msgid.link/20260303030335.766779-2-xiaoyao.li@intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/amd/ibs: Avoid calling perf_allow_kernel() from the IBS NMI handler</title>
<updated>2026-05-23T11:06:25+00:00</updated>
<author>
<name>Ravi Bangoria</name>
<email>ravi.bangoria@amd.com</email>
</author>
<published>2026-02-16T04:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2783ed2442ce69ae240b787aee6dae801cef7aec'/>
<id>urn:sha1:2783ed2442ce69ae240b787aee6dae801cef7aec</id>
<content type='text'>
[ Upstream commit b0a09142622a994c4f4088c3f61db5da87cfc711 ]

Calling perf_allow_kernel() from the NMI context is unsafe and could be
fatal. Capture the permission at event-initialization time by storing it
in event-&gt;hw.flags, and have the NMI handler rely on that cached flag
instead of making the call directly.

Fixes: 50a53b60e141d ("perf/amd/ibs: Prevent leaking sensitive data to userspace")
Reported-by: Sadasivan Shaiju &lt;sadasivan.shaiju2@amd.com&gt;
Signed-off-by: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: https://patch.msgid.link/20260216042216.1440-5-ravi.bangoria@amd.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf/amd/ibs: Preserve PhyAddrVal bit when clearing PhyAddr MSR</title>
<updated>2026-05-23T11:06:25+00:00</updated>
<author>
<name>Ravi Bangoria</name>
<email>ravi.bangoria@amd.com</email>
</author>
<published>2026-02-16T04:22:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aaf2712f76747830043ef5dfd5ef2c46f01bd830'/>
<id>urn:sha1:aaf2712f76747830043ef5dfd5ef2c46f01bd830</id>
<content type='text'>
[ Upstream commit 723a290326e015b07931eabc603d3735999377be ]

Commit 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to
userspace") zeroed the physical address and also cleared the PhyAddrVal
flag before copying the value into a perf sample to avoid exposing
physical addresses to unprivileged users.

Clearing PhyAddrVal, however, has an unintended side-effect: several
other IBS fields are considered valid only when this bit is set. As a
result, those otherwise correct fields are discarded, reducing IBS
functionality.

Continue to zero the physical address, but keep the PhyAddrVal bit
intact so the related fields remain usable while still preventing any
address leak.

Fixes: 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace")
Signed-off-by: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: https://patch.msgid.link/20260216042216.1440-4-ravi.bangoria@amd.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
