summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-01-13KVM: SVM: Check for an unexpected VM-Exit after RETPOLINE "fast" handlingSean Christopherson
Check for an unexpected/unhandled VM-Exit after the manual RETPOLINE=y handling. The entire point of the RETPOLINE checks is to optimize for common VM-Exits, i.e. checking for the rare case of an unsupported VM-Exit is counter-productive. This also aligns SVM and VMX exit handling. No functional change intended. Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: SVM: Open code handling of unexpected exits in svm_invoke_exit_handler()Sean Christopherson
Fold svm_check_exit_valid() and svm_handle_invalid_exit() into their sole caller, svm_invoke_exit_handler(), as having tiny single-use helpers makes the code unncessarily difficult to follow. This will also allow for additional cleanups in svm_invoke_exit_handler(). No functional change intended. Suggested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Link: https://patch.msgid.link/20251230211347.4099600-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: SVM: Add a helper to detect VMRUN failuresSean Christopherson
Add a helper to detect VMRUN failures so that KVM can guard against its own long-standing bug, where KVM neglects to set exitcode[63:32] when synthesizing a nested VMFAIL_INVALID VM-Exit. This will allow fixing KVM's mess of treating exitcode as two separate 32-bit values without breaking KVM-on-KVM when running on an older, unfixed KVM. Cc: Jim Mattson <jmattson@google.com> Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251230211347.4099600-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: x86: align the code with kvm_x86_call()Jun Miao
The use of static_call_cond() is essentially the same as static_call() on x86 (e.g. static_call() now handles a NULL pointer as a NOP), and then the kvm_x86_call() is added to improve code readability and maintainability for keeping consistent code style. Fixes 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Link: https://lore.kernel.org/all/3916caa1dcd114301a49beafa5030eca396745c1.1679456900.git.jpoimboe@kernel.org/ Link: https://lore.kernel.org/r/20240507133103.15052-3-wei.w.wang@intel.com Signed-off-by: Jun Miao <jun.miao@intel.com> Link: https://patch.msgid.link/20260105065423.1870622-1-jun.miao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()Sean Christopherson
Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVM_EXIT_UNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as *something* has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects. As explained in the Fixes commits, it _should_ be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MP_STATE and/or injected events, and thus put the vCPU into what should be an impossible state. Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where _KVM_ would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running. Cc: Alessandro Ratti <alessandro@0x65c.net> Cc: stable@vger.kernel.org Fixes: 26844fee6ade ("KVM: x86: never write to memory from kvm_vcpu_check_block()") Fixes: 45405155d876 ("KVM: x86: WARN if a vCPU gets a valid wakeup that KVM can't yet inject") Link: https://syzkaller.appspot.com/text?tag=ReproC&x=10d4261a580000 Reported-by: syzbot+1522459a74d26b0ac33a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/671bc7a7.050a0220.455e8.022a.GAE@google.com Link: https://patch.msgid.link/20260109030657.994759-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: SVM: Tag sev_supported_vmsa_features as read-only after initSean Christopherson
Tag sev_supported_vmsa_features with __ro_after_init as it's configured by sev_hardware_setup() and never written after initial configuration (and if it were, that'd be a blatant bug). Opportunistically relocate the variable out of the module params area now that sev_es_debug_swap_enabled is gone (which largely motivated its original location). Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260109033101.1005769-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: SVM: Drop the module param to control SEV-ES DebugSwapSean Christopherson
Rip out the DebugSwap module param, as the sequence of events that led to its inclusion was one big mistake, the param no longer serves any purpose. Commit d1f85fbe836e ("KVM: SEV: Enable data breakpoints in SEV-ES") goofed by not adding a way for the userspace VMM to control the feature. Functionally, that was fine, but it broke attestation signatures because SEV_FEATURES are included in the signature. Commit 5abf6dceb066 ("SEV: disable SEV-ES DebugSwap by default") fixed that issue, but the underlying flaw of userspace not having a way to control SEV_FEATURES was still there. That flaw was addressed by commit 4f5defae7089 ("KVM: SEV: introduce KVM_SEV_INIT2 operation"), and so then 4dd5ecacb9a4 ("KVM: SEV: allow SEV-ES DebugSwap again") re-enabled DebugSwap by default. Now that the dust has settled, the module param doesn't serve any meaningful purpose. Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260109033101.1005769-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: x86: Update APICv ISR (a.k.a. SVI) as part of kvm_apic_update_apicv()Sean Christopherson
Fold the calls to .hwapic_isr_update() in kvm_apic_set_state(), kvm_lapic_reset(), and __kvm_vcpu_update_apicv() into kvm_apic_update_apicv(), as updating SVI is directly related to updating KVM's own cache of ISR information, e.g. SVI is more or less the APICv equivalent of highest_isr_cache. Note, calling .hwapic_isr_update() during kvm_apic_update_apicv() has benign side effects, as doing so changes the orders of the calls in kvm_lapic_reset() and kvm_apic_set_state(), specifically with respect to to the order between .hwapic_isr_update() and .apicv_post_state_restore(). However, the changes in ordering are glorified nops as the former hook is VMX-only and the latter is SVM-only. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to set virtual APICv mode on-demand if L2 is activeSean Christopherson
If L1's virtual APIC mode changes while L2 is active, e.g. because L1 doesn't intercept writes to the APIC_BASE MSR and L2 changes the mode, temporarily load vmcs01 and do all of the necessary actions instead of deferring the update until the next nested VM-Exit. This will help in fixing yet more issues related to updates while L2 is active, e.g. KVM neglects to update vmcs02 MSR intercepts if vmcs01's MSR intercepts are modified while L2 is active. Not updating x2APIC MSRs is benign because vmcs01's settings are not factored into vmcs02's bitmap, but deferring the x2APIC MSR updates would create a weird, inconsistent state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to update APIC page on-demand if L2 is activeSean Christopherson
If the KVM-owned APIC-access page is migrated while L2 is running, temporarily load vmcs01 and immediately update APIC_ACCESS_ADDR instead of deferring the update until the next nested VM-Exit. Once changing the virtual APIC mode is converted to always do on-demand updates, all of the "defer until vmcs01 is active" logic will be gone. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to refresh APICv controls on-demand if L2 is activeSean Christopherson
If APICv is (un)inhibited while L2 is running, temporarily load vmcs01 and immediately refresh the APICv controls in vmcs01 instead of deferring the update until the next nested VM-Exit. This all but eliminates potential ordering issues due to vmcs01 not being synchronized with kvm_lapic.apicv_active, e.g. where KVM _thinks_ it refreshed APICv, but vmcs01 still contains stale state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to update SVI on-demand if L2 is activeSean Christopherson
If APICv is activated while L2 is running and triggers an SVI update, temporarily load vmcs01 and immediately update SVI instead of deferring the update until the next nested VM-Exit. This will eventually allow killing off kvm_apic_update_hwapic_isr(), and all of nVMX's deferred APICv updates. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to update TPR threshold on-demand if L2 is activeSean Christopherson
If KVM updates L1's TPR Threshold while L2 is active, temporarily load vmcs01 and immediately update TPR_THRESHOLD instead of deferring the update until the next nested VM-Exit. Deferring the TPR Threshold update is relatively straightforward, but for several APICv related updates, deferring updates creates ordering and state consistency problems, e.g. KVM at-large thinks APICv is enabled, but vmcs01 is still running with stale (and effectively unknown) state. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13KVM: nVMX: Switch to vmcs01 to update PML controls on-demand if L2 is activeSean Christopherson
If KVM toggles "CPU dirty logging", a.k.a. Page-Modification Logging (PML), while L2 is active, temporarily load vmcs01 and immediately update the relevant controls instead of deferring the update until the next nested VM-Exit. For PML, deferring the update is relatively straightforward, but for several APICv related updates, deferring updates creates ordering and state consistency problems, e.g. KVM at-large thinks APICv is enabled, but vmcs01 is still running with stale (and effectively unknown) state. Convert PML first precisely because it's the simplest case to handle: if something is broken with the vmcs01 <=> vmcs02 dance, then hopefully bugs will bisect here. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://patch.msgid.link/20260109034532.1012993-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13x86/entry/vdso32: When using int $0x80, use it directlyH. Peter Anvin
When neither sysenter32 nor syscall32 is available (on either FRED-capable 64-bit hardware or old 32-bit hardware), there is no reason to do a bunch of stack shuffling in __kernel_vsyscall. Unfortunately, just overwriting the initial "push" instructions will mess up the CFI annotations, so suffer the 3-byte NOP if not applicable. Similarly, inline the int $0x80 when doing inline system calls in the vdso instead of calling __kernel_vsyscall. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-11-hpa@zytor.com
2026-01-13x86/cpufeature: Replace X86_FEATURE_SYSENTER32 with X86_FEATURE_SYSFAST32H. Peter Anvin
In most cases, the use of "fast 32-bit system call" depends either on X86_FEATURE_SEP or X86_FEATURE_SYSENTER32 || X86_FEATURE_SYSCALL32. However, nearly all the logic for both is identical. Define X86_FEATURE_SYSFAST32 which indicates that *either* SYSENTER32 or SYSCALL32 should be used, for either 32- or 64-bit kernels. This defaults to SYSENTER; use SYSCALL if the SYSCALL32 bit is also set. As this removes ALL existing uses of X86_FEATURE_SYSENTER32, which is a kernel-only synthetic feature bit, simply remove it and replace it with X86_FEATURE_SYSFAST32. This leaves an unused alternative for a true 32-bit kernel, but that should really not matter in any way. The clearing of X86_FEATURE_SYSCALL32 can be removed once the patches for automatically clearing disabled features has been merged. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-10-hpa@zytor.com
2026-01-13x86/vdso: Abstract out vdso system call internalsH. Peter Anvin
Abstract out the calling of true system calls from the vdso into macros. It has been a very long time since gcc did not allow %ebx or %ebp in inline asm in 32-bit PIC mode; remove the corresponding hacks. Remove the use of memory output constraints in gettimeofday.h in favor of "memory" clobbers. The resulting code is identical for the current use cases, as the system call is usually a terminal fallback anyway, and it merely complicates the macroization. This patch adds only a handful of more lines of code than it removes, and in fact could be made substantially smaller by removing the macros for the argument counts that aren't currently used, however, it seems better to be general from the start. [ v3: remove stray comment from prototyping; remove VDSO_SYSCALL6() since it would require special handling on 32 bits and is currently unused. (Uros Biszjak) Indent nested preprocessor directives. ] Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Uros Bizjak <ubizjak@gmail.com> Link: https://patch.msgid.link/20251216212606.1325678-9-hpa@zytor.com
2026-01-13x86/entry/vdso: Include GNU_PROPERTY and GNU_STACK PHDRsH. Peter Anvin
Currently the vdso doesn't include .note.gnu.property or a GNU noexec stack annotation (the -z noexecstack in the linker script is ineffective because we specify PHDRs explicitly.) The motivation is that the dynamic linker currently do not check these. However, this is a weak excuse: the vdso*.so are also supposed to be usable at link libraries, and there is no reason why the dynamic linker might not want or need to check these in the future, so add them back in -- it is trivial enough. Use symbolic constants for the PHDR permission flags. [ v4: drop unrelated formatting changes ] Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-8-hpa@zytor.com
2026-01-13x86/entry/vdso32: Remove open-coded DWARF in sigreturn.SH. Peter Anvin
The vdso32 sigreturn.S contains open-coded DWARF bytecode, which includes a hack for gdb to not try to step back to a previous call instruction when backtracing from a signal handler. Neither of those are necessary anymore: the backtracing issue is handled by ".cfi_entry simple" and ".cfi_signal_frame", both of which have been supported for a very long time now, which allows the remaining frame to be built using regular .cfi annotations. Add a few more register offsets to the signal frame just for good measure. Replace the nop on fallthrough of the system call (which should never, ever happen) with a ud2a trap. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-7-hpa@zytor.com
2026-01-13x86/entry/vdso32: Remove SYSCALL_ENTER_KERNEL macro in sigreturn.SH. Peter Anvin
A macro SYSCALL_ENTER_KERNEL was defined in sigreturn.S, with the ability of overriding it. The override capability, however, is not used anywhere, and the macro name is potentially confusing because it seems to imply that sysenter/syscall could be used here, which is NOT true: the sigreturn system calls MUST use int $0x80. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-6-hpa@zytor.com
2026-01-13x86/entry/vdso32: Don't rely on int80_landing_pad for adjusting ipH. Peter Anvin
There is no fundamental reason to use the int80_landing_pad symbol to adjust ip when moving the vdso. If ip falls within the vdso, and the vdso is moved, we should change the ip accordingly, regardless of mode or location within the vdso. This *currently* can only happen on 32 bits, but there isn't any reason not to do so generically. Note that if this is ever possible from a vdso-internal call, then the user space stack will also needed to be adjusted (as well as the shadow stack, if enabled.) Fortunately this is not currently the case. At the moment, we don't even consider other threads when moving the vdso. The assumption is that it is only used by process freeze/thaw for migration, where this is not an issue. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-5-hpa@zytor.com
2026-01-13x86/entry/vdso: Refactor the vdso buildH. Peter Anvin
- Separate out the vdso sources into common, vdso32, and vdso64 directories. - Build the 32- and 64-bit vdsos in their respective subdirectories; this greatly simplifies the build flags handling. - Unify the mangling of Makefile flags between the 32- and 64-bit vdso code as much as possible; all common rules are put in arch/x86/entry/vdso/common/Makefile.include. The remaining is very simple for 32 bits; the 64-bit one is only slightly more complicated because it contains the x32 generation rule. - Define __DISABLE_EXPORTS when building the vdso. This need seems to have been masked by different ordering compile flags before. - Change CONFIG_X86_64 to BUILD_VDSO32_64 in vdso32/system_call.S, to make it compatible with including fake_32bit_build.h. - The -fcf-protection= option was "leaking" from the kernel build, for reasons that was not clear to me. Furthermore, several distributions ship with it set to a default value other than "-fcf-protection=none". Make it match the configuration options for *user space*. Note that this patch may seem large, but the vast majority of it is simply code movement. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-4-hpa@zytor.com
2026-01-13x86/entry/vdso: Move vdso2c to arch/x86/toolsH. Peter Anvin
It is generally better to build tools in arch/x86/tools to keep host cflags proliferation down, and to reduce makefile sequencing issues. Move the vdso build tool vdso2c into arch/x86/tools in preparation for refactoring the vdso makefiles. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-3-hpa@zytor.com
2026-01-13x86/entry/vdso: Rename vdso_image_* to vdso*_imageH. Peter Anvin
The vdso .so files are named vdso*.so. These structures are binary images and descriptions of these files, so it is more consistent for them to have a naming that more directly mirrors the filenames. It is also very slightly more compact (by one character...) and simplifies the Makefile just a little bit. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251216212606.1325678-2-hpa@zytor.com
2026-01-13KVM: SVM: Fix a missing kunmap_local() in sev_gmem_post_populate()Yan Zhao
sev_gmem_post_populate() needs to unmap the target vaddr after copy_from_user() to the vaddr fails. Fixes: dee5a47cc7a4 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command") Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Link: https://patch.msgid.link/20260108214622.1084057-2-michael.roth@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-01-13arch/um: remove unused varible err in remove_files_and_dir()Alex Shi
err is duplicated with errno, and never used; remove it. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Shi <alexs@kernel.org> Link: https://patch.msgid.link/20260107064009.15380-1-alexs@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13um: virtio_uml: Support adding devices via mconsoleTiwei Bie
It can be used when we want to add virtio devices to UML while it's up and running. Virtio devices can be added to UML using the same syntax as the command line option: (mconsole) config virtio_uml.device=<socket>:<virtio_id>[:<platform_id>] Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20260106004259.1604736-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13um: Handle SIGCHLD in seccomp mode like other IRQ signalsTiwei Bie
In seccomp mode, SIGCHLD serves as the child reaper IRQ. So, let's handle it in the same way as other IRQ signals, including preventing them from nesting with each other and allowing interrupted syscalls to be automatically restarted. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20260106001228.1531146-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13um: Preserve errno within signal handlerTiwei Bie
We rely on errno to determine whether a syscall has failed, so we need to ensure that accessing errno is async-signal-safe. Currently, we preserve the errno in sig_handler_common(), but it doesn't cover every possible case. Let's do it in hard_handler() instead, which is the signal handler we actually register. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20260106001228.1531146-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-13arm64: dts: qcom: qcs8300: Add GPU coolingGaurav Kohli
Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. Set up GPU cooling by throttling the GPU speed when reaching 115°C. Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250903-a623-gpu-support-v5-4-5398585e2981@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull x86 kvm fixes from Paolo Bonzini: - Avoid freeing stack-allocated node in kvm_async_pf_queue_task - Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: selftests: kvm: Verify TILELOADD actually #NM faults when XFD[18]=1 selftests: kvm: try getting XFD and XSAVE state out of sync selftests: kvm: replace numbered sync points with actions x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 x86/kvm: Avoid freeing stack-allocated node in kvm_async_pf_queue_task
2026-01-14riscv: dts: allwinner: d1: Add RGB LEDs to boardsSamuel Holland
Some D1-based boards feature an onboard RGB LED. Enable them. Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Tested-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://patch.msgid.link/20231029212738.7871-6-samuel@sholland.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-01-14riscv: dts: allwinner: d1: Add LED controller nodeSamuel Holland
Allwinner D1 contains an LED controller. Add its devicetree node, as well as the pinmux used by the reference board design. Acked-by: Guo Ren <guoren@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Tested-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://patch.msgid.link/20231029212738.7871-5-samuel@sholland.org [wens@kernel.org: move "status" to end of properties] Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-01-14arm64: dts: allwinner: a100: Add LED controller nodeSamuel Holland
Allwinner A100 contains an LED controller. Add it to the devicetree. Acked-by: Guo Ren <guoren@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://patch.msgid.link/20231029212738.7871-4-samuel@sholland.org [wens@kernel.org: resolve conflict; move "status" to end of properties] Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-01-13x86/resctrl: Fix memory bandwidth counter width for HygonXiaochen Shen
The memory bandwidth calculation relies on reading the hardware counter and measuring the delta between samples. To ensure accurate measurement, the software reads the counter frequently enough to prevent it from rolling over twice between reads. The default Memory Bandwidth Monitoring (MBM) counter width is 24 bits. Hygon CPUs provide a 32-bit width counter, but they do not support the MBM capability CPUID leaf (0xF.[ECX=1]:EAX) to report the width offset (from 24 bits). Consequently, the kernel falls back to the 24-bit default counter width, which causes incorrect overflow handling on Hygon CPUs. Fix this by explicitly setting the counter width offset to 8 bits (resulting in a 32-bit total counter width) for Hygon CPUs. Fixes: d8df126349da ("x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper") Signed-off-by: Xiaochen Shen <shenxiaochen@open-hieco.net> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251209062650.1536952-3-shenxiaochen@open-hieco.net
2026-01-13x86/resctrl: Add missing resctrl initialization for HygonXiaochen Shen
Hygon CPUs supporting Platform QoS features currently undergo partial resctrl initialization through resctrl_cpu_detect() in the Hygon BSP init helper and AMD/Hygon common initialization code. However, several critical data structures remain uninitialized for Hygon CPUs in the following paths: - get_mem_config()-> __rdt_get_mem_config_amd(): rdt_resource::membw,alloc_capable hw_res::num_closid - rdt_init_res_defs()->rdt_init_res_defs_amd(): rdt_resource::cache hw_res::msr_base,msr_update Add the missing AMD/Hygon common initialization to ensure proper Platform QoS functionality on Hygon CPUs. Fixes: d8df126349da ("x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper") Signed-off-by: Xiaochen Shen <shenxiaochen@open-hieco.net> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251209062650.1536952-2-shenxiaochen@open-hieco.net
2026-01-13arm64: dts: qcom: sa8775p: Add reg and clocks for QoS configurationOdelu Kukatla
Add register addresses and clocks which need to be enabled for configuring QoS on sa8775p SoC. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251001073344.6599-4-odelu.kukatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13x86/crash: Use set_memory_p() instead of __set_memory_prot()Coiby Xu
set_memory_p() is available to use outside of its compilation unit since: 030ad7af9437 ("x86/mm: Regularize set_memory_p() parameters and make non-static"). There is no use for __set_memory_prot() anymore so drop it too. [ bp: Massage commit message. ] Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260106095100.656292-1-coxu@redhat.com
2026-01-13arm64: dts: rockchip: Add Radxa CM3J on RPi CM4 IO BoardFUKAUMI Naoki
The Raspberry Pi Compute Module 4 IO Board is an application board for the Compute Module 4. [1] This patch adds support for the Radxa CM3J mounted on the RPi CM4 IO Board. Specification: - 12V 5521 DC jack - 2x full-size HDMI 2.0 connectors (only HDMI0 is supported with CM3J) - Gigabit Ethernet RJ45 with PoE support - 2x USB 2.0 connectors, with header for two more connectors - Micro USB connector - microSD card socket - PCIe Gen 2 x1 socket - 12V 4-pin PWM fan connector - External power connector (+5V, +12V) - 2x MIPI DSI connectors - 2x MIPI CSI-2 connectors - 40-pin GPIO header - RTC with battery socket - Red (power) and green (heartbeat) LEDs [1] https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-3-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add Radxa CM3JFUKAUMI Naoki
The Radxa CM3J is a feature rich industrial compute module based on the Rockchip RK3568J SoC. [1] Specification: - Quad-core Cortex-A55 CPU - Mali-G52 2EE GPU - 1TOPS NPU - Up to 8GB LPDDR4x RAM - Up to 32GB eMMC (optional) - 16MB SPI flash (optional) - Wi-Fi 5 / BT 5.0 with external antenna connector - Gigabit Ethernet PHY - RK809 PMIC - Green (power) LED [1] https://dl.radxa.com/cm3j/docs/hw/radxa_cm3j_schematic_v1.2_20250115.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-2-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13x86/pvlocks: Move paravirt spinlock functions into own headerJuergen Gross
Instead of having the pv spinlock function definitions in paravirt.h, move them into the new header paravirt-spinlock.h. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-22-jgross@suse.com
2026-01-13arm64: dts: rockchip: Make eeprom read-only for Radxa ROCK 3C/5A/5CFUKAUMI Naoki
The BL24C16 EEPROM implemented on the Radxa ROCK 3C, 5A, and 5C [1] [2] [3] is designed to have data written during factory programming (regardless of whether data is actually written or not), and we at Radxa permit users to read the data but not write to it. [4] Therefore, we will add a read-only property to the eeprom node. [1] https://dl.radxa.com/rock3/docs/hw/3c/v1400/radxa_rock_3c_v1400_schematic.pdf p.13 [2] https://dl.radxa.com/rock5/5a/docs/hw/radxa_rock5a_V1.1_sch.pdf p.19 [3] https://dl.radxa.com/rock5/5c/docs/hw/v1100/radxa_rock_5c_schematic_v1100.pdf p.18 [4] https://github.com/radxa/u-boot/blob/next-dev-v2024.10/drivers/misc/radxa-i2c-eeprom.c Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108034252.2713-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add TS133 variant of the QNAP NAS seriesHeiko Stuebner
The TS133 is a one-bay NAS mostly similar to the other devices in the series. The main difference is that it is build around the RK3566 SoC instead of the RK3568 variant. The RK3566/RK3568 are mostly similar with only slight variants in both speed and some specific peripherals - the RK3568 has more. The specific for the NAS series stay the same though. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-6-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move copy-key to TSx33 board filesHeiko Stuebner
The copy-key is not present on all device variants, so move it to the individual boards that have this key. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-4-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Fix the common combophy + SATA on QNAP TSx33 devicesHeiko Stuebner
The common used SATA controller on all TSx33 devices is actually SATA2. So move the SATA controller + combophy enablement to their correct position between shared dtsi and board devicetrees. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-3-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move SoC include to individual QNAP TSx33 boardsHeiko Stuebner
The TS133 while mostly similar, is based around the RK3566 variant, so needs a different SoC include. By moving the SoC include to the board devicetrees, we can still keep the shared common setup, while supporting the different base SoCs. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-2-heiko@sntech.de
2026-01-13x86/paravirt: Specify pv_ops array in paravirt macrosJuergen Gross
In order to prepare having multiple pv_ops arrays, specify the array in the paravirt macros. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-21-jgross@suse.com
2026-01-13MIPS: vdso: Provide getres_time64() for 32-bit ABIsThomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-9-97ea7a06a543@linutronix.de
2026-01-13arm64: vdso32: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-8-97ea7a06a543@linutronix.de
2026-01-13ARM: VDSO: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-7-97ea7a06a543@linutronix.de
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-11 23:03:32 +0000