| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Hawi LPASS LPI support
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: 5e91e57e6809 ("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>
|
|
Pull drm fixes from Dave Airlie:
"Weekly pulls request. As expected there is more AMD this week since
Alex was off last week, vmwgfx looks to have been hit with the AI
stick a bit and mediatek as well. Otherwise some minor fixes across
the board, the new normal definitely seems to be a thing.
dp:
- Restrict some DP bandwidth calculations to HDMI DFP
bridge:
- Fix small leak in bridge/display-connector
mediatek:
- Check CRTC state before freeing
- mtk_hdmi: Fix DDC adapter double put in v2
- mtk_hdmi_common: take i2c adapter module reference
- mtk_dsi: Enable HS clock only at pre-enable
- ovl_adaptor: balance component registrations
amdgpu:
- VCN 5.3 fix
- UserQ fixes
- GEM close optimization
- HDMI AV mute fix
- UML build fixes
- GFXOFF residency metrics fixes
- SMU 15 fixes
- debug_vm fix
- PSP 15 fixes
- NBIO 7.11.5 fix
- pptable use after free fix
- gpu metrics fetch fix
- DC viewport fix
- DML2.1 fix
- i2c retimer spam fix
- UMD profile pstate fix
- Power metrics format cleanup
- GTT size fix on APUs
- DC context logging fix
- PM sysfs fix for APUs
- Follow on pageflip timeout fix
amdkfd:
- Various bounds checking fixes
- Mutex locking fix
i915/xe:
- Check no-DMA huge-pte cases before DMA segment test
- sink FRL rate fix
- 200ms fix for TMDS scrambler status
vmwgfx:
- Improve various size checks and limit checks
- Fix oops when submitting invalid execbuf ioctl
- Correctly lock in vmfwgx fence signaling path
- More validation of execbuf ioctl
- Fix oops in vmwgfx vkms init failure path
- Overflow handling in shader path
panthor:
- Improve firmware validation
imagination:
- Improve imagination trace points.
qaic:
- Fix QAIC transaction length check"
* tag 'drm-fixes-2026-08-01' of https://gitlab.freedesktop.org/drm/kernel: (59 commits)
drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status
drm/amd/display: Exit idle optimizations before programming
drm/amd/pm: hide pp_table sysfs on APUs
accel/qaic: use sizeof(*trans_hdr) for transaction length check
drm/panthor: validate firmware interface structure sizes
drm/xe/pt: check no-DMA huge-pte cases before DMA segment test
drm/imagination: Update the trace point pvr_job_submit_fw()
drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoder
drm/mediatek: ovl_adaptor: balance component registrations
drm/mediatek: mtk_dsi: Enable HS clock only at pre-enable
drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs
drm/amd/display: use proper context for logging
drm/amdgpu: cap GTT size to physical RAM on APUs
drm/amd/pm: use milliwatts for GPU power sensors
drm/amdgpu: restore UMD profile pstate after runtime resume
drm/amd/display: Silence link_dpms I2C retimer failures
drm/amdkfd: hold event_mutex while checkpointing CRIU events
drm/amd/display: check if dml21_add_phantom_plane() is successful
drm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewport
drm/amd/display: Add AV mute wait frames to dce110_set_avmute
...
|
|
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: 88c51002d06f9a68 ("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 6b2658b3f36a ("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: 6b2658b3f36a ("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 94cb9e8f270797e489633cfa53d2d44afecb8bef.
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: 6455a8a84bdfd ("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>
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
- Wait on external BO kernel fences in exec IOCTL (Brost)
- General clean-up (Anas)
- Documentation fix (Rafael)
- Add a debugfs for pcode information (Karthik)
- Free madvise VMA array on L2 flush failure (Guangshuo)
- Page Table related fixes (Shuicheng, Zongyao)
- Improvements GuC error handling and GuC small fixes (Sk, Zhanjun, Arvind)
- Add new W/As (Daniele, Harish)
- GuC paging engine support (Auld)
- Add and use more KLV helpers (Michal)
- Balance exec queue suspend/resume (Niranjana, Thomas)
- Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC (Himal)
- SRIOV: Disable display in admin only PF mode (Satya)
- Fix writable override for CRI NVM (Sasha)
- Fix VF CCS attach/detach race with in-flight BO moves (Brost)
- Introduce Xe Uncorrectable Error Handling (Riana)
- Fix WOPCM size for LNL+ (Daniele)
- Consolidate debugfs fault injection functions (Mallesh)
- Multi-queue related fixes and improvements (Niranjana, Jagmeet, Shuicheng)
- Add RAS GPU health indicator (Soham)
- PAT related improvements (Roper, Sanjay)
- NULL deref fix on migration on VF (Satya)
- i2c related fix (Raag)
- Fix SVM leak and clean up xe_vm_create (Shuicheng)
- Drop force_probe requirement for NVL-s (Gustavo)
- Optimise TT population for DONTNEED BOs (Auld)
- Add page size allocation mode control and coverage (Himal, Nareshkumar)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/amt2kDVdyBK6VEyU@intel.com
|
|
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: 2bb8cafea80b ("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>
|
|
Add and use a KVM wrapper for pthread_create() syscall so that selftests
don't need to manually assert that the syscall succeeded.
Note, most tests don't actually assert success, but they all obviously
rely on the syscall to succeed.
Other than explicitly failing if pthread_create() fails, no functional
change intended.
Link: https://patch.msgid.link/20260731195612.2697986-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop all of the code that is unreachable in the hardware disable test, as
it adds a lot of noise that makes the test seem far more complicated than
it actually is.
Link: https://patch.msgid.link/20260731195612.2697986-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Affine the worker threads to random CPUs in the hardware disable test, and
honor the starting CPU set in the process. Hardcoding to CPUs 0-3 is both
wrong and less interesting than running on random CPUs.
Opportunistically convert the local 'i' to an int, as the macros it tests
against are signed, and using 'i' as an iterator is conventionally declared
as an int.
Link: https://patch.msgid.link/20260731195612.2697986-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Extract kvm_pick_random_cpu() out of pin_task_to_random_cpu() so that tests
can choose a random CPU without having to immediately pin a task to that
CPU.
No functional change intended.
Link: https://patch.msgid.link/20260731195612.2697986-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
When pinning a task to a random CPU, return which CPU the task was pinned
to so that the caller can do things like avoid running other tasks on the
target CPU.
Link: https://patch.msgid.link/20260731195612.2697986-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
When building against a libc that provides pthread_attr_setaffinity_np(),
pre-set the grandchildren threads CPU affinity in the hardware disable test
to further reduce the perceived latency of pthread_create(). On large NUMA
systems, this reduces the average runtime from ~10s to ~5s.
Link: https://patch.msgid.link/20260731195612.2697986-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
disable test
Affine worker threads to their target pCPU set *before* doing any work in
the hardware disable test. When running a preemptible kernel on a NUMA
system with a large number of CPUs (100+ of CPUs), waiting to set the
affinity of the grandchildren until after the grandchild is fully spun up
results in total test runtimes of over a minute, presumably due to
cross-node NUMA penalties and scheduler lock contention.
E.g. from the perspective of the caller, when waiting to affine the tasks,
pthread_create() takes ~100x longer.
Link: https://patch.msgid.link/20260731195612.2697986-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add and use a KVM wrapper for sched_setaffinity() so that selftests don't
need to manually assert that the syscall succeeded.
No functional change intended.
Link: https://patch.msgid.link/20260731195612.2697986-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
This patch fixes the issue where encoder or decoder widget
types are assigned kcontrols in a topology but get ignored.
The controls were parsed successfully but were not registered
as ALSA kcontrols.
In dapm_create_or_share_kcontrol() the snd_soc_dapm_encoder
and the snd_soc_dapm_decoder are added to the switch statement
to be handled similarly as e.g. the snd_soc_dapm_effect for
assigning a proper long control name.
In dapm_widget_show_component() the snd_soc_dapm_encoder and
the snd_soc_dapm_decoder are added to switch statement to let
them to be shown in the debugfs power state output.
In snd_soc_dapm_new_widgets() the snd_soc_dapm_encoder and the
snd_soc_dapm_decoder are added to same switch case handling as
e.g. snd_soc_dapm_effect to be registered with dapm_new_pga().
The previous operation with default in the switch statement
silently ignored them. Note: Despite the function name, the
dapm_new_pga() is generic utility that calls
dapm_create_or_share_kcontrol() for each kcontrol of the widget.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260730125600.6491-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Due to a widespread Intel erratum (e.g. EMR158), programming the
VMX-preemption timer with certain large values may cause the timer to
expire earlier than expected. The recommended workaround is to cap the
VMX-preemption timer value to strictly less than:
2^25 * CPUID.15H:EBX[31:0] / CPUID.15H:EAX[31:0].
Calculate the maximum "safe" preemption timer value during hardware setup
based on CPUID 15H when available, and use the adjusted max value in all
locations where KVM currently hardcodes the max architectural value,
including in the subtle case where KVM soft-disables the timer.
Don't apply the workaround when running as a VM, because absent explicit
enumeration to state the bug is present (or not), it's L0's responsibility
to faithfully emulate/virtualize the VMX preemption timer.
WARN if the above logic would result in a max value of zero and fall back
to the maximum architectural value, as the expectation is that real
hardware will never provide problematic EAX/EBX values (which is another
reason to ignore the erratum when running as a VM; there's less chance of
a false positive on the WARN due to L0 providing an unanticipated ratio).
Reported-by: Sean Christopherson <seanjc@google.com>
Closes: https://lore.kernel.org/all/Zn9X0yFxZi_Mrlnt@google.com/
Suggested-by: Chao Gao <chao.gao@intel.com>
Assisted-by: Gemini:Gemini-Next
Reviewed-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
[sean: track inclusive max instead of exclusive limit, massage changelog]
Link: https://patch.msgid.link/20260731171926.2629627-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Double down on using the VMX preemption timer only for 64-bit kernels, and
bury the setup and runtime adjustment code, and all global variables, under
CONFIG_X86_64=y. This will allow addressing a widespread Intel erratum
without running afoul of unused-but-set-variable and __udivdi3() errors on
32-bit kernels.
No functional change intended.
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Reviewed-by: Chao Gao <chao.gao@intel.com>
Link: https://patch.msgid.link/20260731171926.2629627-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Use parsed CPUID(0x0) instead of a direct CPUID query.
[ bp: Drop the unnecessary NULL check. ]
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-10-darwi@linutronix.de
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
Pull hyper-v fixes from Wei Liu:
- Multiple fixes for the MSHV driver (Stanislav Kinsburskii, Wei Liu,
Yi Xie, Yousef Alhouseen)
- Multiple fixes for the VMBus driver (Hardik Garg, Michael Kelley,
Sebastian Andrzej Siewior)
* tag 'hyperv-fixes-signed-20260731' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
mshv_vtl: bounds-check cpu index in vtl mmap fault handler
mshv: Publish VP to pt_vp_array before installing the file descriptor
Drivers: hv: vmbus: add VTL2 redirect connection ID
mshv: Order pt_vp_array publish against irqfd assertion path
mshv: Fix missing error code on VP allocation failure
mshv: Fix level-triggered check on uninitialized data
mshv: Fix race in mshv_irqfd_deassign
mshv: Use kfree_rcu in mshv_portid_free
mshv: Fix sleeping under spinlock in mshv_portid_alloc
mshv: Fix duplicate GSI detection for GSI 0
Drivers: hv: vmbus: Remove vmbus_irq_initialized
Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep annotation
mshv_vtl: fix fd leak in mshv_ioctl_create_vtl()
mshv_vtl: clear hypercall output before copyout
Drivers: hv: vmbus: Set DMA coherent mask for VMBus devices
mshv: fix hv_input_get_system_property struct
|
|
Casefolding filesystems can request a specific version of UTF-8 at
mount-time. utf8_parse_version then assembles the "major.minor.rev"
string into an unsigned int. There were two issues with the parser
logic: first, individual fields are read as signed int, allowing
negative numbers, second, an overflowed field will result in unexpected
results. Something like the below actually succeeds to mount using
utf8-12.1.0.
mount -t tmpfs -o casefold=utf8-12.0.256 none /mnt
[ 10.867859] tmpfs: Using encoding : utf8-12.1.0
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
|
|
Chi-Wen Weng <cwweng.linux@gmail.com> says:
Add devicetree binding and SPI controller driver support for the Quad SPI
controller found in Nuvoton MA35D1 SoCs.
The controller provides two native chip selects and supports standard SPI
and spi-mem operations using single, dual and quad bus widths.
This initial implementation uses 8-bit PIO transfers and supports
per-operation clock configuration, clock and reset handling, and direct
execution of SPI memory operations. DMA and active-high chip select support
are intentionally left out of the initial driver.
Link: https://patch.msgid.link/20260731023818.1626075-1-cwweng.linux@gmail.com
|
|
Add SPI controller driver support for the Quad SPI controller found in
Nuvoton MA35D1 SoCs.
The controller provides two native chip selects and supports standard SPI
and spi-mem operations, including single-bit full-duplex transfers and
dual or quad half-duplex transfers. Implement 8-bit PIO transfers,
per-operation clock configuration, clock and reset handling, and direct
execution of SPI memory operations.
Limit individual transfers to 4 KiB and SPI messages to 8 KiB to keep the
PIO polling path bounded. Read the optional num-cs property and fall back
to the hardware default of two chip selects when it is not present.
Active-high chip select and DMA transfers are not supported by this
initial implementation.
Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
Link: https://patch.msgid.link/20260731023818.1626075-3-cwweng.linux@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
