Add regs overrides for PM8950 codec and implement matching reg overrides
via compatible.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Link: https://patch.msgid.link/20260730174353.108023-14-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the compatible for SDM660 and SDM670 devices, which can use the
support for WCD codecs connected to internal MI2S.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-13-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The LPI_MI2S_RX_0 and LPI_MI2S_TX_3 ports on SDM660 can be connected to
the digital and analog WCD codecs. They can be supported with the same
logic for other ports, but just need to be explicitly stated. Add
support for these ports.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-12-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On SDM660, LPI MI2S ports can be connected to a WCD codec which may
support headphones. Register the headphone jack on codecs connected to
the playback port, LPI_MI2S_RX_0.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-11-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the ASM-AFE routing for LPI MI2S ports which represent internal MI2S
ports on SDM660.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-10-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The bindings for LPI MI2S ports, originally exclusive to q6apm, can be
used for internal MI2S ports on q6afe. Add the internal MI2S ports found
on the SDM660 internal sound card using the LPI MI2S bindings.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-9-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The bindings for LPI MI2S ports, originally exclusive to q6apm, can be
used for internal MI2S ports on q6afe. Add the port mappings for
internal MI2S, found on the Snapdragon 660 internal sound card.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-8-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MSM8916 digital codec is also found on SDM660, typically connected to
the SDM660 internal sound card. Provide a space
for specific compatibles and add the compatible for SDM660.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-6-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8953 (cajon 2.0) revision of the PM8916 analog codec is also found
on PM660L, typically connected to the SDM660 internal sound card via the
digital codec. Provide a space for specific compatibles and add the
compatible for PM660L.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-5-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Document pm8950 and pm8953 analog audio codecs.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
[richard: add back empty line]
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-4-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 7 internal MI2S ports per direction found on devices with the
internal sound card for Snapdragon 660. This is similar to the LPI MI2S
ports, and the LPI MI2S bindings can be reused for internal MI2S. Extend
the bindings for LPI MI2S ports to accommodate the internal MI2S ports.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-3-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatibles for sdm660 based soundcards.
Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-2-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:
The series first documents the WSA885X devicetree binding,
including supplies, GPIOs, Interrupt and battery configuration.
It then adds the ASoC codec driver with register programming, serial
interface setup, clock handling, mute and gain control, reset handling,
interrupt support, runtime TDM slot-count configuration, and stream-time
power-state sequencing.
validated speaker playback on Shikra and Hawi platforms.
Link: https://patch.msgid.link/20260715115220.3093799-1-prasad.kumpatla@oss.qualcomm.com
Add an ASoC codec driver for the Qualcomm WSA885X stereo smart speaker
amplifier.
The driver programs the register map, handles reset and interrupt support,
exposes DAI operations for PCM/TDM playback, and provides mixer controls
for usage mode, speaker volume and RX slot mask.
Keep stream-time power-state sequencing in the DAI callbacks and use regmap
for the control path.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715115220.3093799-3-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add bindings for the Qualcomm WSA8855 stereo smart speaker amplifier.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715115220.3093799-2-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmpsr6kQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpqS9D/9pDdC3GR86wPrkkujlr7NZ3HZ58mAS2JAF
3QYTgKWbZPcAFVwFk4Hknd5ukVLAz6Pb2nQRDl2FGaI4wx9K9AMCYruIelI3TZUq
3GX65ndPvtfIN+DOqGjLZRHISa1iwBvN0K5Mon6GvQuxuazTnj1v2GpiYufNAjW2
n+X2L9m6Y+ltDakks/YPYto5FnOhs6fOjx+gP+yZ5einCMDrGBhrkt5G0PoUKQ7F
MDBa+wkUmJF6NbewKwsLd5YSEnaQ+rfNL8eBamlSptIo4GKVwcyknKM7ubXQ1YKj
5Z2/cpn7WhaucCZrsYqaSko3MH2A20CQCBx/+MNjlU+86AryQXLgxAU0XS1ML9Q2
yR74WTfvkTWgdMPsBUiY11hvPd4G2jiBKOCQ6AuSAW2fErAt4KHt3MgFjfoRLcu0
FKnFll1FQsP8dkBQ9UmA0KvTmwsF/R+VPdvvCVzzu3Nw9MGvx8nUetbt3E9t4eLw
uh7Lf+kNiggP4Q053uBjEfJUivJf+Uqq7AkTurkQqNjYw0aoo7x66bKtWr6FOkI8
sUpAlX9hzPBclpol/aSsU9LSRuc2MBv8ys3geoorQsXnxalPaZTvN41OcqARssin
+Iy1pCw6JpjR/5P75IV4RfCl39qxjyQ2RyM8Dwl/2Qe2fecZLkndAsQeRkKH/lHk
lgpIuNBVOA==
=dZCX
-----END PGP SIGNATURE-----
Merge tag 'io_uring-7.2-20260731' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Fix for a bug in how length caps are handled in multishot, and along
with it, a generic fix for avoiding these kinds of conversion issues
in the future.
- Ensure that task restrictions are always preserved across exec.
- Revert of the io_uring controlled epoll restriction, which disallowed
nested contexts. Turns out that libuv is already using it like that,
so we cannot simply remove it, sadly.
- Fix for a reference leak in the zcrx code.
* tag 'io_uring-7.2-20260731' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring: preserve task restrictions across exec
io_uring/zcrx: don't clear master_ctx from the import path
Revert "io_uring/epoll: disallow adding an epoll file to an epoll context"
io_uring/kbuf: cap buffer selection length at MAX_RW_COUNT
io_uring/net: initialize mshot_len for send
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:
This series adds support for LPASS low-power resource (LPR) voting
through PRM and introduces LPASS LPI TLMM pinctrl support for newer
platforms such as Hawi.
On such platforms, LPASS requires LPR resource voting via PRM to keep
the subsystem active. This is handled by adding a new clock ID and
support for PARAM_ID_RSC_CPU_LPR in q6prm.
Additionally, a new LPASS LPI TLMM block is introduced, requiring a
dedicated DT binding and pinctrl driver.
Link: https://patch.msgid.link/20260724141708.2212057-1-prasad.kumpatla@oss.qualcomm.com
Add support for issuing LPASS low-power resource (LPR) votes through
the PRM interface.
Some platforms (e.g. Hawi) require the LPASS to be kept active via LPR
resource voting instead of the existing hardware core vote mechanism.
Handle this by introducing support for PARAM_ID_RSC_CPU_LPR when the
LPR vote clock ID is requested.
For LPR requests, use the appropriate parameter ID and payload format
to disable CPU subsystem sleep, ensuring that the LPASS register space
remains accessible.
Also add the corresponding clock mapping for LPASS_HW_LPR_VOTE.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-4-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Q6DSP_MAX_CLK_ID defines the upper bound of supported clock
identifiers in the qdsp6 LPASS clock driver.
Increase the maximum clock ID value to accommodate the LPASS
LPR vote clock identifier.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-3-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new clock ID, LPASS_HW_LPR_VOTE, to represent the LPASS low-power
resource (LPR) vote through the PRM interface.
The LPASS PRM supports a resource voting mechanism to control low-power
states via PARAM_ID_RSC_CPU_LPR. Exposing this as a q6prm clock ID allows
clients to request the LPR vote using the existing qcom,q6prm clock
provider interface.
This functionality is required on newer platforms (e.g. Hawi) where LPASS
clients need to explicitly manage LPR resource voting via PRM.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-2-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix spelling and abbreviation errors in the PTT packet decoder:
- HISI_PTT_FIELD_LENTH -> HISI_PTT_FIELD_LENGTH
- hisi_ptt_8dw_kpt_desc -> hisi_ptt_8dw_pkt_desc
- hisi_ptt_4dw_kpt_desc -> hisi_ptt_4dw_pkt_desc
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Fix pre-existing robustness issues in the hisi-ptt auxtrace decoder
reported by Sashiko:
1. Endianness in hisi_ptt_check_packet_type(): The first 32-bit word was
read with a host-endian memory cast (*(uint32_t *)buf). On big-endian
hosts analyzing a little-endian trace, the bit[31:11] 8DW magic check
fails and every 8DW packet is misclassified as 4DW. Read the header
with get_unaligned_le32().
2. Heap out-of-bounds read: hisi_ptt_dump() called
hisi_ptt_check_packet_type() which dereferenced 4 bytes of the buffer
without any size check. A malformed or truncated event with
auxtrace.size in {0,1,2,3} may cause a heap OOB read. Pass the buffer
length to hisi_ptt_check_packet_type() and return (defaulting to
4DW) when the buffer is shorter than HISI_PTT_FIELD_LENTH.
3. Integer truncation: event->auxtrace.size is __u64 but was stored in
an int. Traces larger than 2GB became negative (malloc failure), and
huge sizes wrapping to a small positive caused a short readn() that
left unread payload in the pipe and permanently desynchronized the
stream. Use u64 for the size, reject anything larger than SSIZE_MAX
before malloc (same bound used by auxtrace_copy_data()), and compare
readn()'s return value against (ssize_t)size to detect truncation.
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
TLP Headers traced by HiSilicon PCIe tune and trace device (PTT) in
4DW format are shown in the document as below:
bits [31:30] [ 29:25 ][24][23][22][21][ 20:11 ][ 10:0 ]
|-----|---------|---|---|---|---|-------------|-------------|
DW0 [ Fmt ][ Type ][T9][T8][TH][SO][ Length ][ Time ]
DW1 [ Header DW1 ]
DW2 [ Header DW2 ]
DW3 [ Header DW3 ]
Problem:
The DW0 bit field layout of the hisi_ptt_4dw union does not match the
actual bit ordering in little-endian memory, causing incorrect field
decoding.
Test on Kunpeng 930 SOC, generating data flow with `iperf` commands:
- server side:
iperf -s
- client side:
iperf -c $ip_addr -t 30
Trace the TLP headers with hisi_ptt on server side at the same time:
perf record -e hisi_ptt12_0/type=4,filter=0x05101,direction=2,format=0/ \
--max-size 50M -o perf.data &
The trace aims to capture completion TLPs, learn more in the document:
https://docs.kernel.org/trace/hisi-ptt.html
Decode perf.data with hisi_ptt decoder:
perf report -D
The hisi_ptt decoder produces the following result:
[...perf headers and other information]
. ... HISI PTT data: size 8388608 bytes
. 00000000: 68 87 20 94 Format 3 Type 1a T9 0 T8 1 TH 1 SO 1 Length 10 Time 4a1
. 00000004: 40 00 00 00 Header DW1
. 00000008: 40 00 01 51 Header DW2
. 0000000c: 00 00 00 00 Header DW3
[...other hisi_ptt TLP headers]
According to PCIe r5.0 sec 2.2.1, the Fmt & Type of Cpl/CplD is supposed
to be 8b'00001010' / 8b'01001010'
However, the Format & Type decoder analyzing result is 8b'01111010'.
It does not match field encodings of any TLP.
Correct decoder result should be:
[...perf headers and other information]
. ... HISI PTT data: size 8388608 bytes
. 00000000: 94 20 87 68 Format 2 Type a T9 0 T8 0 TH 0 SO 1 Length 10 Time 768
. 00000004: 00 00 00 40 Header DW1
. 00000008: 51 01 00 40 Header DW2
. 0000000c: 00 00 00 00 Header DW3
[...other hisi_ptt TLP headers]
To solve the problem:
1. Drop the union and C bitfield struct, store the raw DW value in
a plain uint32_t, and extract the fields with FIELD_GET() against
GENMASK/BIT masks declared in the header so they can be reused by
other translation units. The masks are portable across endianness and
compilers.
2. Print all DW hex values in big-endian byte order for readability,
matching the bit field layout shown in the 4DW format diagram.
3. Read the DW value with get_unaligned_le32() instead of an unaligned
pointer cast, avoiding both strict-aliasing violations and
alignment hazards on hosts that do not support unaligned access.
Cc: stable@vger.kernel.org
Fixes: 5e91e57e68 ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet")
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
cu_walk_functions_at() calls libdw_a2l_cb() with the containing
DW_TAG_subprogram DIE first, then each DW_TAG_inlined_subroutine
nested inside. The callback treated both the same way, causing two
bugs:
1) die_name() returns the unqualified DW_AT_name, so every C++
frame lost its namespace/class prefix (ns::Class::method
collapsed to method).
2) new_inline_sym() re-uses base_sym only when funcname matches
base_sym->name exactly; otherwise it fabricates a fake symbol
tagged "(inlined)". Any mismatch between the DWARF name and
the ELF symbol name mis-tags an outer, non-inline frame as
inlined. This hits C++ (die_name()'s unqualified output never
matches the demangled ELF symbol) and it also hits C functions
that GCC IPA-cloned (foo vs foo.isra.0 / .constprop / .part /
.cold), since DW_AT_linkage_name doesn't reflect those renames.
Fix both:
* Prefer die_get_linkage_name() (mangled, fully qualified),
falling back to die_name() when absent (C, extern "C").
new_inline_sym() already demangles via dso__demangle_sym().
* For DW_TAG_subprogram DIEs, use base_sym directly -- the DIE
tag already tells us it is the outer function, sidestepping
the name comparison entirely for both C++ qualification and
GCC IPA-clone renames.
Fixes: 88c51002d0 ("perf addr2line: Add a libdw implementation")
Signed-off-by: Michael Liang <mliang@purestorage.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
KVM_CAP_VM_TYPES advertises the bitmap of VM types that KVM_CREATE_VM
accepts, but nothing verified that the ioctl actually enforces it: that
every advertised type can be created and every non-advertised type is
rejected. sev_init2_tests carried a TODO for this ("check that
unsupported types cannot be created. Probably a separate selftest"),
but the check is not specific to SEV or KVM_SEV_INIT2, and not even to
x86.
Add a standalone test that walks the type space and, for each value,
asserts that KVM_CREATE_VM succeeds iff the corresponding bit is set in
KVM_CAP_VM_TYPES, and otherwise fails with -EINVAL. The walk extends
past bit 31 so that out-of-range type values, which can never be
advertised in the u32 bitmap, are also confirmed to be rejected. The
test only depends on KVM_CAP_VM_TYPES, so it lives in the common set and
is skipped on architectures that don't advertise the capability.
Drop the now-addressed TODO from sev_init2_tests.c.
Tested on an AMD SEV-SNP capable host. With KVM_CAP_VM_TYPES=0x15
(DEFAULT/SEV/SNP), only the advertised types are created and everything
else is rejected:
$ strace -e trace=ioctl ./vm_types_test 2>&1 | grep KVM_CREATE_VM
ioctl(3, KVM_CREATE_VM, 0) = 4 # DEFAULT
ioctl(3, KVM_CREATE_VM, 0x1) = -1 EINVAL # SW_PROTECTED
ioctl(3, KVM_CREATE_VM, 0x2) = 4 # SEV
ioctl(3, KVM_CREATE_VM, 0x3) = -1 EINVAL # SEV-ES
ioctl(3, KVM_CREATE_VM, 0x4) = 4 # SNP
ioctl(3, KVM_CREATE_VM, 0x5) = -1 EINVAL # TDX
... 0x6..0x3f all -1 EINVAL ...
Reloading kvm_amd with sev_snp=0 drops the bitmap to 0x5 and only types
0 and 2 are then created, confirming the test tracks the advertised set
rather than hard-coded types.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260710050442.826777-1-hemanth.selam@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The libdw callback API has two levels: dwfl_getthread_frames() first finds
the requested thread using the next_thread() or get_thread() callback and
then walks its stack.
Since perf only has a snapshot of the stack of a single thread, it
provides a stubbed-out API that always returns the pid the Dwfl was
attached with (i.e. whatever was passed to dwfl_attach_state()), rather
than the actual sampled thread's TID.
Commit 6b2658b3f3 ("perf unwind-libdw: Don't discard loaded ELF/DWARF
after every unwind") changed libdw unwinding from recreating the Dwfl
object for each sample to caching it in struct maps, which is shared by
every thread in the process. It left next_thread() unchanged.
Since the pid passed to dwfl_attach_state() is only set at creation, only
the thread of the first sample is ever found. As a result,
dwfl_getthread_frames() fails with ESRCH when asked to unwind a sample
from another thread.
Make next_thread() return the current sample's TID, provide get_thread()
so libdw can find it directly, and pass the process PID expected by
dwfl_attach_state(). This allows libdw to unwind samples from every thread
in a multi-threaded process.
Add a shell regression test that records a four-thread workload and
verifies that libdw recovers the worker callchain for every worker TID.
Fixes: 6b2658b3f3 ("perf unwind-libdw: Don't discard loaded ELF/DWARF after every unwind")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Alessio Podda <aleph.pi.gh@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The snd_sof_pcm_period_elapsed function currently schedules work on the
system-wide workqueue. This can lead to potential delays or jitter in
audio processing if the system workqueue is busy with other tasks.
To improve real-time performance and ensure timely processing of PCM
periods, we can use the system_highpri_wq instead of the default work
queue.
In performance testing, this change significantly reduced the observed
scheduling delays. For instance, under load(stressapptest -M 15000 -m
60), the maximum delay dropped from 9ms on the system workqueue to 5ms
on the dedicated high-priority workqueue.
Suggested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260730130445.8277-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
vCPU creation in kvm_vm_ioctl_create_vcpu() may fail after
kvm_arch_vcpu_create() -> vmx_vcpu_create() already succeeded. In such
case kvm_vm_ioctl_create_vcpu() destroys the newly created vCPU in the
failure path. However, that leaves a side effect: the IPIv pid_table
entry remains configured with this vCPU's pi_desc address. As a result,
when another vCPU sends an IPI to the APIC ID of this failed-to-create
vCPU, it will cause HW to write to this (freed!) pi_desc memory. [*]
Fix this by clearing the pid_table entry when destroying the vCPU.
Note that the same issue exists for SVM AVIC as well [1], to be fixed.
[*] Although, since this memory is freed into the kvm_vcpu_cache kmem
cache which is only used for allocating kvm_vcpus, _maybe_ this
memory will only be reused for pi_desc of another vCPU, not for
anything else. So _maybe_ this will only result in delivering the
IPI to a wrong vCPU (possibly of another VM) in the worst case, not
in a random corruption of kernel memory.
Link: https://lore.kernel.org/kvm/al4rNqpBYy8FGKPw@blrnaveerao1 [1]
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Link: https://patch.msgid.link/20260729170621.308809-3-dmaluka@chromium.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
If userspace tries to create a vCPU with the same vcpu_id as an existing
one, kvm_vm_ioctl_create_vcpu() checks for that and fails with -EEXIST
only after it already created the vCPU via kvm_arch_vcpu_create(). As a
result, even though this newly created vCPU is destroyed in the failure
path, the fact that it is temporarily created with an invalid vcpu_id
and that there are temporarily two vCPUs with the same vcpu_id is a
potential source of subtle issues.
In particular, this prevents fixing an VMX IPIv issue where a stale entry
left in the VM's PI descriptor table after the vCPU is destroyed in the
failure path. The right way to fix that issue is to clear that entry when
destroying the vCPU, however right now that would have a nasty side effect:
since the same entry is used for the other, previously created vCPU with
same vcpu_id, clearing it would mean effectively disabling IPIv for that
existing good vCPU.
So to avoid this and similar problems, check for duplicate vcpu_id as
early in the vCPU creation path as possible, before
kvm_arch_vcpu_create() and even before kvm_arch_vcpu_precreate().
Simply moving the existing kvm_get_vcpu_by_id() check earlier doesn't work,
as kvm->lock is dropped and reacquired, i.e. moving kvm_get_vcpu_by_id()
would introduce a race:
1. vCPU A is being created but not installed in kvm->vcpu_array yet.
2. vCPU B with the same vcpu_id is being created. It passes the
duplicated vcpu_id check, since the check doesn't find vCPU A in
kvm->vcpu_array.
3. vCPU A is installed in kvm->vcpu_array, vCPU creation succeeds.
4. vCPU B with the same vcpu_id is installed in kvm->vcpu_array, vCPU
creation succeeds.
So introduce the bitmap of vcpu_ids used by the VM, in order to safely
check if the given vcpu_id is used and mark is as used before releasing
kvm->lock first time.
Alternatively, KVM could use another Xarray[*] for roughly the same code
complexity, which would minimize KVM's steady state memory footprint at
the cost of higher runtime latency (to allocate and free entries). Given
that the worst case scenario is 256 bytes per-VM (on x86, which allows up
to 16KiB vCPU IDs), go with the slightly simpler approach until there's a
need to save memory.
Suggested-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/kvm/al6eg7C-2sDBEAFD@google.com [*]
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Link: https://patch.msgid.link/20260729170621.308809-2-dmaluka@chromium.org
[sean: massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
When virtual APIC access acceleration is enabled (APICv on Intel, AVIC
on AMD), vcpu creation installs a private memory slot at the default
APIC base address (0xfee00000). If a user memory region overlaps this
address, vcpu creation fails with EEXIST. The same error occurs when
installing an overlapping user memory region after vcpu creation.
This also applies when using KVM_CAP_SPLIT_IRQCHIP.
This constraint is not documented anywhere. Add a note to the
KVM_CREATE_IRQCHIP and KVM_CAP_SPLIT_IRQCHIP documentation.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Link: https://patch.msgid.link/20260708133856.302151-3-twiederh@redhat.com
[sean: call out "subsequent vcpu creation"]
Signed-off-by: Sean Christopherson <seanjc@google.com>
The kernel rejects KVM_CREATE_IRQCHIP with -EINVAL if any vCPUs have
already been created, but the API documentation does not mention this
constraint. Add a note.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Link: https://patch.msgid.link/20260708133856.302151-2-twiederh@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The PCIe link, when down, needs to be recovered to bring it back. But on
some platforms, that cannot be done in a generic way as link recovery
procedure is platform specific. Add a new pci_host_handle_link_down() that
could be called by the host bridge drivers for a specific Root Port when
the link goes down.
pci_host_handle_link_down() accepts a 'pci_dev' corresponding to the Root
Port that observed the link down event. If CONFIG_PCIEAER is enabled, it
calls pcie_do_recovery() with 'pci_channel_io_frozen' as the state. This
will result in the execution of the AER Fatal error handling code. Since
the link down recovery is pretty much the same as AER Fatal error handling,
reuse pcie_do_recovery() here.
The AER .error_detected() callback will be triggered for all of the
downstream devices, but not for the Root Port itself as there is nothing to
do for the Root Ports in the callbacks. Finally, pci_host_reset_root_port()
will be called for the Root Port, which will reset the Root Port using the
.reset_root_port() callback to recover the link. Once that's done, resume
message will be broadcasted to the bridge and the downstream devices,
indicating successful link recovery.
But if CONFIG_PCIEAER is not enabled in the kernel, only
pci_host_reset_root_port() will be called, which will in turn call
pci_bus_error_reset() to just reset the Root Port as there is no way we
could inform the drivers about link recovery.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-3-53570b92064d@oss.qualcomm.com
This reverts commit 94cb9e8f27.
This collides with orthogonal changes in the GPIO tree, we
need to rebase it and apply it to the GPIO tree instead.
Signed-off-by: Linus Walleij <linusw@kernel.org>
On early boot CPU detection, use parsed CPUID(0x1) instead of a direct CPUID
query.
Beside the parser's centralization benefits, use the auto generated CPUID data
types, and their C99 bitfields, instead of doing ugly bitwise operations.
[ bp: - Use a common code pattern for l1 of fetching and checking it
right after that
- flip the check to save an indentation level
- align assignments vertically.
]
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260528153923.403473-12-darwi@linutronix.de
max17040_probe() rejects adapters that do not advertise
I2C_FUNC_SMBUS_BYTE. The driver does not issue SMBus byte transactions,
however. Its regmap has 8-bit registers and 16-bit big-endian values, for
which regmap-i2c supports either raw I2C transfers or SMBus word-data
transactions.
Consequently, an adapter providing raw I2C transfers or SMBus word data
but not SMBus byte transactions is rejected even though regmap can access
the device. Conversely, the current check can pass an adapter that regmap
cannot use.
Drop the stale check and let devm_regmap_init_i2c() validate and select
the supported transfer method.
Fixes: 6455a8a84b ("power: supply: max17040: Use regmap i2c")
Cc: stable@vger.kernel.org
Signed-off-by: Jianing Li <m13940358460@163.com>
Link: https://patch.msgid.link/20260731084259.916-1-m13940358460@163.com
[Fixed Fixes tag, so that it points to the regmap introduction instead of the initial driver addition]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
- Fix NULL bus dereference in of_pci_range_parser_one()
- Prevent OOB access when too many dynamic reserved memory regions are
defined
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAmptCRcACgkQ+vtdtY28
YcN4oQ/9GJYlymn6frwBmPiG7iVK8OQgvFClUn61/nTuyvaOv5mXDQzbRsP1TqMG
xn+XqAww6XCT4k08bxVe1nORJAIkittVjXLcWLU4EnO7+rHFZnXpEeijWDqMuYT8
rbEArsFyC1u4Uk+TXMwd0lqTZNogrJWR1hXd+T4Kecv+ORVbBeKMdWPZkMdK/KTP
h88iio1V489hdufVMLjcORoySh23i1qJ1qBgjHZIS0lpdBbg2JiXfLvUJHCWHRiU
W2Ucrpz/Wq//86pBie+TWn0IisYOvTB8g/ZLnrG33iN7+HaQMxlP+Cs90V6T9cGi
DQ64LPfvRQrr0KlZ1TxoEy9N2N3SQXJ3l/Hq+nK08B6xlHl+d67cSRzxra/6qs3Z
7scbD5K+K6A9MnSlLn4+wxOyocF/rMHBu+RUUdiO/PqHoFe0TpMR3GHpRysGcebG
OPNbZ1dP8TGaG38wOKj+ZJldoNABO0Sox0/OMv1WNHFbbhoyoDDlajDxJua3lO3U
X4NN/C0bS5EiGSqSZ5SpiAF85Qj13s0RPBB223bEG7PxBA7kfk0UnU/OQwkJLb2y
8GIuG4qWeCXQhcWqxBf++DhmS61LzY3D49qHD4c6oD7ji/3ZGeWR9yyI3o/PQcG+
Gvj4CrQTCicLYgiJxL4VvKuXhXy6JhuJQi/kddO6GfwEyC5IWek=
=9x2Y
-----END PGP SIGNATURE-----
Merge tag 'devicetree-fixes-for-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fixes from Rob Herring:
- Fix NULL bus dereference in of_pci_range_parser_one()
- Prevent out-of-bounds access when too many dynamic reserved memory
regions are defined
* tag 'devicetree-fixes-for-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
of/address: Fix NULL bus dereference in of_pci_range_parser_one()
of: reserved_mem: prevent OOB when too many dynamic regions are defined
Extend the invalid nVMX guest state to cover RSM, i.e. to validate that KVM
synthesizes SHUTDOWN for L1 if SMRAM is clobbered with invalid guest state
during an L2 => SMI => RSM => L2 sequence.
Note, unlike the existing testcase, clobbering SMRAM should result in L1,
not L2, getting SHUTDOWN / TRIPLE_FAULT, as RSM is architecturally defined
to trigger shutdown if the CPU detects invalid state.
Signed-off-by: Hao Zhang <hao_zhang_kdev@163.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Link: https://patch.msgid.link/20260731173340.2644656-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
In the invalid nVMX guest state test, extract the creation of the VM and
initial running of the vCPU to get to L2 into helpers so that the common
code can be reused to extend the test to also cover RSM.
Eliminate the unnecessary global "vm", and opportunistically free the VM
after the testcase as there's zero reason not to.
Opportunistically assert that L2 is never resumed after the I/O exit to L1,
e.g. to guard against false passes.
Link: https://patch.msgid.link/20260731173340.2644656-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use port 0x80 instead of 0x2000 to trigger an L2 => L0 VM-Exit in the nVMX
invalid guest state test, so that the test can be expanded to cover RSM in
the L2 => SMI => L2 path without having to manually encode a MOV to DX (the
immediate form of IN only supports an imm8).
Use port 0x80 as it's a well-known port and is used by other tests, e.g. in
the coalesced I/O test.
Link: https://patch.msgid.link/20260731173340.2644656-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Rework .vcpu_pre_run() into a more specific .vcpu_needs_initialization() to
consolidate the SNP and TDX control flows, and to eliminate the potentially
confusing almost-collision between svm_vcpu_pre_run() and pre_sev_run(): the
former is SEV specific, but is pre-KVM_RUN, whereas the latter is pre-VMRUN.
Link: https://patch.msgid.link/20260731173340.2644656-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Synthesize SHUTDOWN (for L1) if L2 requires unhandleable emulation after
loading guest state from SMRAM during RSM to prevent a misbehaving L1 (or
userspace via L1) from tripping the sanity check that KVM doesn't try to
cancel a pending nested VM-Enter. If SMRAM is modified such that RSM will
load what should be impossible state for L2, then KVM will detect that it
needs to emulate the current code stream and will abort VM-Entry to L2.
And because KVM (rightly) expects such a scenario to be impossible, KVM
WARNs and bugs the VM.
__ret && !(vcpu->kvm)->vm_bugged
WARNING: arch/x86/kvm/vmx/vmx.c:6741 at vmx_handle_exit+0x65/0x790 [kvm_intel], CPU#13: vmx_invalid_nes/2902
Modules linked in: kvm_intel kvm irqbypass [last unloaded: kvm]
CPU: 13 UID: 1000 PID: 2902 Comm: vmx_invalid_nes Tainted: G W 7.2.0-rc2 #124 PREEMPT
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:vmx_handle_exit+0x65/0x790 [kvm_intel]
Call Trace:
<TASK>
kvm_arch_vcpu_ioctl_run+0xdf8/0x1d00 [kvm]
kvm_vcpu_ioctl+0x2d5/0x960 [kvm]
__x64_sys_ioctl+0x8a/0xd0
do_syscall_64+0xb7/0x570
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
Alternatively, KVM could suppress the WARN for the RSM case, but that would
still leave the vCPU in a "bad" state that KVM doesn't know how to handle
(which is also why KVM rejects attempts to do KVM_RUN when the vCPU is
loaded with invalid state). And architecturally, the Intel SDM explicitly
states that RSM leads to shutdown if the CPU detects invalid state.
Fixes: 2bb8cafea8 ("KVM: vVMX: signal failure for nested VMEntry if emulation_required")
Reported-by: Hao Zhang <zhanghao1@kylinos.cn>
Link: https://patch.msgid.link/20260731173340.2644656-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Expose VMX's check for unhandleable emulation as its own kvm_x86_ops hook,
and move the actual pre-KVM_RUN check into common x86. This will allow
sharing the core logic with KVM's RSM emulation without needed to add a
post-RSM hook, and is a step towards removing the .vcpu_pre_run() hook
entirely.
Alternatively, KVM could provide a post-RSM hook as mentioned, but pre/post
hooks tend to be unwieldy as the exact "timing" of the call often matters
greatly. E.g. in this case, the call must slot in exactly between loading
guest state from SMRAM and the hack to force the vCPU out of L2 on SHUTDOWN.
Link: https://patch.msgid.link/20260731173340.2644656-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add and use KVM wrappers for pthread_{g,s}etaffinity_np() so that selftests
don't need to manually assert that the syscalls succeeded, and so that they
don't need to manually pass in sizeof(cpu_set_t) for the size.
Link: https://patch.msgid.link/20260731195612.2697986-12-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The x86 library provides x86_family() and x86_model(). They take raw
CPUID register output and calculate the CPU family and model from it.
In follow-up work, the x86 subsystem will use APIs which access
previously-parsed CPUID leafs structure instead of doing direct CPUID queries.
These new APIs force using the auto generated leaf data types at
<asm/cpuid/leaf_types.h>.
Introduce x86 family and model calculation functions that take these
auto-generated data types. Refactor the original code so that no logic is
duplicated.
[ bp: Massage commit message, unbreak too long line. ]
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260528153923.403473-11-darwi@linutronix.de
Rename the global constants in the hardware disable test to better
capture what they control, and open code the literal number of sleeping
tasks and iterations instead of using power-of-2 math to express values
that are 100% arbitrary.
Opportunistically tag the global semaphore with "static".
No functional change intended.
Link: https://patch.msgid.link/20260731195612.2697986-13-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Deduplicate test code that does cancel()+join() on pthreads by adding a
collection of syscall wrappers. The tests that asynchronously cancel
pthreads, i.e. use PTHREAD_CANCEL_ASYNCHRONOUS, are particularly ugly,
especially since it's not immediately obvious why those tests assert on
the thread being CANCELED, whereas others do not.
No functional change intended.
Link: https://patch.msgid.link/20260731195612.2697986-11-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add and use KVM wrappers for pthread_{cancel,join}() so that selftests
don't need to manually assert that the syscalls succeeded.
Note, the vast majority tests don't actually assert success, but they all
obviously rely on the syscall to succeed.
Other than explicitly failing if a syscall fails, no functional change
intended.
Link: https://patch.msgid.link/20260731195612.2697986-10-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
