aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-08-19perf/x86/core: Set pebs_capable and PMU_FL_PEBS_ALL for the BaselinePeter Zijlstra2-4/+1
The SDM explicitly states that PEBS Baseline implies Extended PEBS. For cpu model forward compatibility (e.g. on ICX, SPR, ADL), it's safe to stop doing FMS table thing such as setting pebs_capable and PMU_FL_PEBS_ALL since it's already set in the intel_ds_init(). The Goldmont Plus is the only platform which supports extended PEBS but doesn't have Baseline. Keep the status quo. Reported-by: Like Xu <likexu@tencent.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lkml.kernel.org/r/20220816114057.51307-1-likexu@tencent.com
2022-08-19perf/x86/lbr: Enable the branch type for the Arch LBR by defaultKan Liang1-0/+8
On the platform with Arch LBR, the HW raw branch type encoding may leak to the perf tool when the SAVE_TYPE option is not set. In the intel_pmu_store_lbr(), the HW raw branch type is stored in lbr_entries[].type. If the SAVE_TYPE option is set, the lbr_entries[].type will be converted into the generic PERF_BR_* type in the intel_pmu_lbr_filter() and exposed to the user tools. But if the SAVE_TYPE option is NOT set by the user, the current perf kernel doesn't clear the field. The HW raw branch type leaks. There are two solutions to fix the issue for the Arch LBR. One is to clear the field if the SAVE_TYPE option is NOT set. The other solution is to unconditionally convert the branch type and expose the generic type to the user tools. The latter is implemented here, because - The branch type is valuable information. I don't see a case where you would not benefit from the branch type. (Stephane Eranian) - Not having the branch type DOES NOT save any space in the branch record (Stephane Eranian) - The Arch LBR HW can retrieve the common branch types from the LBR_INFO. It doesn't require the high overhead SW disassemble. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220816125612.2042397-1-kan.liang@linux.intel.com
2022-08-19x86/mm: Use proper mask when setting PUD mappingAaron Lu1-1/+1
Commit c164fbb40c43f("x86/mm: thread pgprot_t through init_memory_mapping()") mistakenly used __pgprot() which doesn't respect __default_kernel_pte_mask when setting PUD mapping. Fix it by only setting the one bit we actually need (PSE) and leaving the other bits (that have been properly masked) alone. Fixes: c164fbb40c43 ("x86/mm: thread pgprot_t through init_memory_mapping()") Signed-off-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-19KVM: VMX: Heed the 'msr' argument in msr_write_intercepted()Jim Mattson1-2/+1
Regardless of the 'msr' argument passed to the VMX version of msr_write_intercepted(), the function always checks to see if a specific MSR (IA32_SPEC_CTRL) is intercepted for write. This behavior seems unintentional and unexpected. Modify the function so that it checks to see if the provided 'msr' index is intercepted for write. Fixes: 67f4b9969c30 ("KVM: nVMX: Handle dynamic MSR intercept toggling") Cc: Sean Christopherson <seanjc@google.com> Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220810213050.2655000-1-jmattson@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19kvm: x86: mmu: Always flush TLBs when enabling dirty loggingJunaid Shahid3-42/+61
When A/D bits are not available, KVM uses a software access tracking mechanism, which involves making the SPTEs inaccessible. However, the clear_young() MMU notifier does not flush TLBs. So it is possible that there may still be stale, potentially writable, TLB entries. This is usually fine, but can be problematic when enabling dirty logging, because it currently only does a TLB flush if any SPTEs were modified. But if all SPTEs are in access-tracked state, then there won't be a TLB flush, which means that the guest could still possibly write to memory and not have it reflected in the dirty bitmap. So just unconditionally flush the TLBs when enabling dirty logging. As an alternative, KVM could explicitly check the MMU-Writable bit when write-protecting SPTEs to decide if a flush is needed (instead of checking the Writable bit), but given that a flush almost always happens anyway, so just making it unconditional seems simpler. Signed-off-by: Junaid Shahid <junaids@google.com> Message-Id: <20220810224939.2611160-1-junaids@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19kvm: x86: mmu: Drop the need_remote_flush() functionJunaid Shahid1-14/+1
This is only used by kvm_mmu_pte_write(), which no longer actually creates the new SPTE and instead just clears the old SPTE. So we just need to check if the old SPTE was shadow-present instead of calling need_remote_flush(). Hence we can drop this function. It was incomplete anyway as it didn't take access-tracking into account. This patch should not result in any functional change. Signed-off-by: Junaid Shahid <junaids@google.com> Reviewed-by: David Matlack <dmatlack@google.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220723024316.2725328-1-junaids@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19x86/nospec: Fix i386 RSB stuffingPeter Zijlstra1-0/+12
Turns out that i386 doesn't unconditionally have LFENCE, as such the loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such chips. Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence") Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/Yv9tj9vbQ9nNlXoY@worktop.programming.kicks-ass.net
2022-08-19x86/nospec: Unwreck the RSB stuffingPeter Zijlstra1-41/+39
Commit 2b1299322016 ("x86/speculation: Add RSB VM Exit protections") made a right mess of the RSB stuffing, rewrite the whole thing to not suck. Thanks to Andrew for the enlightening comment about Post-Barrier RSB things so we can make this code less magical. Cc: stable@vger.kernel.org Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YvuNdDWoUZSBjYcm@worktop.programming.kicks-ass.net
2022-08-19crypto: x86/sha512 - load based on CPU featuresRobert Elliott1-0/+10
x86 optimized crypto modules built as modules rather than built-in to the kernel end up as .ko files in the filesystem, e.g., in /usr/lib/modules. If the filesystem itself is a module, these might not be available when the crypto API is initialized, resulting in the generic implementation being used (e.g., sha512_transform rather than sha512_transform_avx2). In one test case, CPU utilization in the sha512 function dropped from 15.34% to 7.18% after forcing loading of the optimized module. Add module aliases for this x86 optimized crypto module based on CPU feature bits so udev gets a chance to load them later in the boot process when the filesystems are all running. Signed-off-by: Robert Elliott <elliott@hpe.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-08-19Merge tag 'kvmarm-fixes-6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEADPaolo Bonzini5-7/+12
KVM/arm64 fixes for 6.0, take #1 - Fix unexpected sign extension of KVM_ARM_DEVICE_ID_MASK - Tidy-up handling of AArch32 on asymmetric systems
2022-08-19ARM: dts: versatile: Update spi clock-names propertyKuldeep Singh1-1/+1
Now that spi pl022 binding only accept "sspclk" as clock name, versatile platform with "SSPCLK" clock name start raising dtbs_check warnings. Make necessary changes to update this property in order to make it compliant with binding. clock-names:0: 'sspclk' was expected Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com> Link: https://lore.kernel.org/r/20220312113853.63446-4-singh.kuldeep87k@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-08-19ARM: dts: realview: Update spi clock-names propertyKuldeep Singh4-4/+4
Now that spi pl022 binding only accept "sspclk" as clock name, realview platforms with "SSPCLK" clock name start raising dtbs_check warnings. Make necessary changes to update this property in order to make it compliant with binding. clock-names:0: 'sspclk' was expected Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com> Link: https://lore.kernel.org/r/20220312113853.63446-3-singh.kuldeep87k@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-08-19ARM: dts: integratorap: Update spi node propertiesKuldeep Singh1-2/+2
As per spi pl022 binding, SPI clock name is "sspclk" and not "spiclk". Fix it. Also update ssp node name to enable spi bindings check. Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com> Link: https://lore.kernel.org/r/20220312113853.63446-2-singh.kuldeep87k@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-08-19x86/kvm: Fix "missing ENDBR" BUG for fastop functionsJosh Poimboeuf1-1/+2
The following BUG was reported: traps: Missing ENDBR: andw_ax_dx+0x0/0x10 [kvm] ------------[ cut here ]------------ kernel BUG at arch/x86/kernel/traps.c:253! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <TASK> asm_exc_control_protection+0x2b/0x30 RIP: 0010:andw_ax_dx+0x0/0x10 [kvm] Code: c3 cc cc cc cc 0f 1f 44 00 00 66 0f 1f 00 48 19 d0 c3 cc cc cc cc 0f 1f 40 00 f3 0f 1e fa 20 d0 c3 cc cc cc cc 0f 1f 44 00 00 <66> 0f 1f 00 66 21 d0 c3 cc cc cc cc 0f 1f 40 00 66 0f 1f 00 21 d0 ? andb_al_dl+0x10/0x10 [kvm] ? fastop+0x5d/0xa0 [kvm] x86_emulate_insn+0x822/0x1060 [kvm] x86_emulate_instruction+0x46f/0x750 [kvm] complete_emulated_mmio+0x216/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x604/0x650 [kvm] kvm_vcpu_ioctl+0x2f4/0x6b0 [kvm] ? wake_up_q+0xa0/0xa0 The BUG occurred because the ENDBR in the andw_ax_dx() fastop function had been incorrectly "sealed" (converted to a NOP) by apply_ibt_endbr(). Objtool marked it to be sealed because KVM has no compile-time references to the function. Instead KVM calculates its address at runtime. Prevent objtool from annotating fastop functions as sealable by creating throwaway dummy compile-time references to the functions. Fixes: 6649fa876da4 ("x86/ibt,kvm: Add ENDBR to fastops") Reported-by: Pengfei Xu <pengfei.xu@intel.com> Debugged-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Message-Id: <0d4116f90e9d0c1b754bb90c585e6f0415a1c508.1660837839.git.jpoimboe@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19x86/kvm: Simplify FOP_SETCC()Josh Poimboeuf1-19/+4
SETCC_ALIGN and FOP_ALIGN are both 16. Remove the special casing for FOP_SETCC() and just make it a normal fastop. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Message-Id: <7c13d94d1a775156f7e36eed30509b274a229140.1660837839.git.jpoimboe@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19x86/ibt, objtool: Add IBT_NOSEAL()Josh Poimboeuf1-0/+11
Add a macro which prevents a function from getting sealed if there are no compile-time references to it. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Message-Id: <20220818213927.e44fmxkoq4yj6ybn@treble> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19KVM: Rename mmu_notifier_* to mmu_invalidate_*Chao Peng12-36/+36
The motivation of this renaming is to make these variables and related helper functions less mmu_notifier bound and can also be used for non mmu_notifier based page invalidation. mmu_invalidate_* was chosen to better describe the purpose of 'invalidating' a page that those variables are used for. - mmu_notifier_seq/range_start/range_end are renamed to mmu_invalidate_seq/range_start/range_end. - mmu_notifier_retry{_hva} helper functions are renamed to mmu_invalidate_retry{_hva}. - mmu_notifier_count is renamed to mmu_invalidate_in_progress to avoid confusion with mn_active_invalidate_count. - While here, also update kvm_inc/dec_notifier_count() to kvm_mmu_invalidate_begin/end() to match the change for mmu_notifier_count. No functional change intended. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com> Message-Id: <20220816125322.1110439-3-chao.p.peng@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19KVM: Rename KVM_PRIVATE_MEM_SLOTS to KVM_INTERNAL_MEM_SLOTSChao Peng1-1/+1
KVM_INTERNAL_MEM_SLOTS better reflects the fact those slots are KVM internally used (invisible to userspace) and avoids confusion to future private slots that can have different meaning. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com> Message-Id: <20220816125322.1110439-2-chao.p.peng@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-19KVM: MIPS: remove unnecessary definition of KVM_PRIVATE_MEM_SLOTSPaolo Bonzini1-2/+0
KVM_PRIVATE_MEM_SLOTS defaults to zero, so it is not necessary to define it in MIPS's asm/kvm_host.h. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-18riscv: traps: add missing prototypeConor Dooley2-1/+4
Sparse complains: arch/riscv/kernel/traps.c:213:6: warning: symbol 'shadow_stack' was not declared. Should it be static? The variable is used in entry.S, so declare shadow_stack there alongside SHADOW_OVERFLOW_STACK_SIZE. Fixes: 31da94c25aea ("riscv: add VMAP_STACK overflow detection") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220814141237.493457-5-mail@conchuod.ie Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-18riscv: signal: fix missing prototype warningConor Dooley2-0/+13
Fix the warning: arch/riscv/kernel/signal.c:316:27: warning: no previous prototype for function 'do_notify_resume' [-Wmissing-prototypes] asmlinkage __visible void do_notify_resume(struct pt_regs *regs, All other functions in the file are static & none of the existing headers stood out as an obvious location. Create signal.h to hold the declaration. Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220814141237.493457-4-mail@conchuod.ie Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-08-18ARM: dts: qcom: msm8974: add rpm-stats device nodeDmitry Baryshkov1-0/+5
Add device node for the rpm-stats pseudo device. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220726205355.598874-2-dmitry.baryshkov@linaro.org
2022-08-18ARM: dts: qcom: apq8084: add rpm-stats device nodeDmitry Baryshkov1-0/+5
Add device node for the rpm-stats pseudo device. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220726205355.598874-1-dmitry.baryshkov@linaro.org
2022-08-18ARM: multi_v7_defconfig: enable more Qualcomm driversKrzysztof Kozlowski1-0/+4
Enable Qualcomm drivers: 1. Command DB (used in SDX55 and SDX65). 2. On Chip Memory - OCMEM (used in MSM8974) 3. RPMh and RPMh Power domain (used in SDX55 and SDX65). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220727065830.10681-3-krzysztof.kozlowski@linaro.org
2022-08-18ARM: qcom_defconfig: enable more Qualcomm driversKrzysztof Kozlowski1-0/+4
Enable Qualcomm drivers: 1. socinfo driver to provide some basic information about the SoC being used. 2. Remote filesystem memory driver (used in MSM8974). 3. RPM Power domain (used in MSM8226). 4. Sleep stats driver (used in MSM8916, MSM8974 and APQ8084). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220727065830.10681-2-krzysztof.kozlowski@linaro.org
2022-08-18arm64: defconfig: enable more Qualcomm driversKrzysztof Kozlowski1-0/+3
Enable Qualcomm drivers: 1. Last Level Cache Controller (many platforms supported). 2. On Chip Memory - OCMEM (used in MSM8992 and MSM8994) 3. Subsystem Power Manager - SPM (used in MSM8916 and SDM660). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220727065830.10681-4-krzysztof.kozlowski@linaro.org
2022-08-18Merge tag 'irqchip-fixes-6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgentThomas Gleixner1-1/+0
Pull irqchip fixes from Marc Zyngier: - A bunch of small fixes for the recently merged LoongArch drivers - A leftover from the non-SMP IRQ affinity rework affecting the Hyper-V IOMMU code Link: https://lore.kernel.org/r/20220812125910.2227338-1-maz@kernel.org
2022-08-18ARM: Kconfig: clean up platform selectionArnd Bergmann22-111/+109
The top-level platform selection is mostly meaningless these days after almost everything is sorted below the CONFIG_ARCH_MULTIPLATFORM, with the only exception being the 20+ year old StrongARM based machines. Make this more consistent by removing the entire choice statement and moving the StrongARM specific options into regular platform specific Kconfig files. The three platforms (footbridge, rpc and sa1100) are still mutually exclusive and cannot coexist with other ARMv4/v5 machines, but since there are only three of them and we will not add more, this can be expressed using Kconfig 'depends on' statements. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-08-18ARM: simplify machdirs/platdirs handlingArnd Bergmann1-26/+10
There is only one plat-* directory left, and the MACHINE variable is only used for the mach/*.h header path. Simplify this by removing the checks for ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, and just adding the include directories for the remaining three platforms manually. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-08-18ARM: remove obsolete Makefile.boot infrastructureArnd Bergmann20-99/+43
There are a number of old Makefile.boot files that remain from the multiplatform conversion, and three that are still in use. These provide the "ZRELADDR", "PARAMS_PHYS" and "INITRD_PHYS" values that are platform specific. It turns out that we can generally just derive this from information that is available elsewhere: - ZRELADDR is normally detected at runtime with the CONFIG_AUTO_ZRELADDR flag, but also needed to be passed to for 'make uImage'. In a multiplatform kernel, one always has to pass this as the $(LOADADDR) variable, but in the StrongARM kernels we can derive it from the sum of $(CONFIG_PHYS_OFFSET) and $(TEXT_OFFSET) that are already known. - PARAMS_PHYS and INITRD_PHYS are only used for bootpImage, which in turn is only used for the pre-ATAGS 'param_struct' based boot interface on StrongARM based machines with old boot loaders. They can both be derived from CONFIG_PHYS_OFFSET and a machine specific offset for the initrd, so all of the logic for these can be part of arch/arm/boot/bootp/Makefile. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-08-18x86/bugs: Add "unknown" reporting for MMIO Stale DataPawan Gupta3-19/+42
Older Intel CPUs that are not in the affected processor list for MMIO Stale Data vulnerabilities currently report "Not affected" in sysfs, which may not be correct. Vulnerability status for these older CPUs is unknown. Add known-not-affected CPUs to the whitelist. Report "unknown" mitigation status for CPUs that are not in blacklist, whitelist and also don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware immunity to MMIO Stale Data vulnerabilities. Mitigation is not deployed when the status is unknown. [ bp: Massage, fixup. ] Fixes: 8d50cdf8b834 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data") Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Suggested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/a932c154772f2121794a5f2eded1a11013114711.1657846269.git.pawan.kumar.gupta@linux.intel.com
2022-08-18x86/clear_user: Make it fasterBorislav Petkov4-43/+185
Based on a patch by Mark Hemment <markhemm@googlemail.com> and incorporating very sane suggestions from Linus. The point here is to have the default case with FSRM - which is supposed to be the majority of x86 hw out there - if not now then soon - be directly inlined into the instruction stream so that no function call overhead is taking place. Drop the early clobbers from the @size and @addr operands as those are not needed anymore since we have single instruction alternatives. The benchmarks I ran would show very small improvements and a PF benchmark would even show weird things like slowdowns with higher core counts. So for a ~6m running the git test suite, the function gets called under 700K times, all from padzero(): <...>-2536 [006] ..... 261.208801: padzero: to: 0x55b0663ed214, size: 3564, cycles: 21900 <...>-2536 [006] ..... 261.208819: padzero: to: 0x7f061adca078, size: 3976, cycles: 17160 <...>-2537 [008] ..... 261.211027: padzero: to: 0x5572d019e240, size: 3520, cycles: 23850 <...>-2537 [008] ..... 261.211049: padzero: to: 0x7f1288dc9078, size: 3976, cycles: 15900 ... which is around 1%-ish of the total time and which is consistent with the benchmark numbers. So Mel gave me the idea to simply measure how fast the function becomes. I.e.: start = rdtsc_ordered(); ret = __clear_user(to, n); end = rdtsc_ordered(); Computing the mean average of all the samples collected during the test suite run then shows some improvement: clear_user_original: Amean: 9219.71 (Sum: 6340154910, samples: 687674) fsrm: Amean: 8030.63 (Sum: 5522277720, samples: 687652) That's on Zen3. The situation looks a lot more confusing on Intel: Icelake: clear_user_original: Amean: 19679.4 (Sum: 13652560764, samples: 693750) Amean: 19743.7 (Sum: 13693470604, samples: 693562) (I ran it twice just to be sure.) ERMS: Amean: 20374.3 (Sum: 13910601024, samples: 682752) Amean: 20453.7 (Sum: 14186223606, samples: 693576) FSRM: Amean: 20458.2 (Sum: 13918381386, sample s: 680331) The original microbenchmark which people were complaining about: for i in $(seq 1 10); do dd if=/dev/zero of=/dev/null bs=1M status=progress count=65536; done 2>&1 | grep copied 32207011840 bytes (32 GB, 30 GiB) copied, 1 s, 32.2 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.93069 s, 35.6 GB/s 37597741056 bytes (38 GB, 35 GiB) copied, 1 s, 37.6 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.78017 s, 38.6 GB/s 62020124672 bytes (62 GB, 58 GiB) copied, 2 s, 31.0 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 2.13716 s, 32.2 GB/s 60010004480 bytes (60 GB, 56 GiB) copied, 1 s, 60.0 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.14129 s, 60.2 GB/s 53212086272 bytes (53 GB, 50 GiB) copied, 1 s, 53.2 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.28398 s, 53.5 GB/s 55698259968 bytes (56 GB, 52 GiB) copied, 1 s, 55.7 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.22507 s, 56.1 GB/s 55306092544 bytes (55 GB, 52 GiB) copied, 1 s, 55.3 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.23647 s, 55.6 GB/s 54387539968 bytes (54 GB, 51 GiB) copied, 1 s, 54.4 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.25693 s, 54.7 GB/s 50566529024 bytes (51 GB, 47 GiB) copied, 1 s, 50.6 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.35096 s, 50.9 GB/s 58308165632 bytes (58 GB, 54 GiB) copied, 1 s, 58.3 GB/s 68719476736 bytes (69 GB, 64 GiB) copied, 1.17394 s, 58.5 GB/s Now the same thing with smaller buffers: for i in $(seq 1 10); do dd if=/dev/zero of=/dev/null bs=1M status=progress count=8192; done 2>&1 | grep copied 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.28485 s, 30.2 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.276112 s, 31.1 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.29136 s, 29.5 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.283803 s, 30.3 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.306503 s, 28.0 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.349169 s, 24.6 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.276912 s, 31.0 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.265356 s, 32.4 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.28464 s, 30.2 GB/s 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 0.242998 s, 35.3 GB/s is also not conclusive because it all depends on the buffer sizes, their alignments and when the microcode detects that cachelines can be aggregated properly and copied in bigger sizes. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/CAHk-=wh=Mu_EYhtOmPn6AxoQZyEh-4fo2Zx3G7rBv1g7vwoKiw@mail.gmail.com
2022-08-18ARM: dts: aspeed: bletchley: Remove hdc1080 nodePotin Lai1-5/+0
Because of incompatible 2nd source si7021, removing hdc1080 node from device tree, and move node probe to user-space layer. Signed-off-by: Potin Lai <potin.lai.pt@gmail.com> Reviewed-by: Patrick Williams <patrick@stwcx.xyz> Link: https://lore.kernel.org/r/20220810004338.329832-3-potin.lai.pt@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-08-18ARM: dts: aspeed: bletchley: Add USB debug card IPMB nodePotin Lai1-0/+8
Add an IPMB node for USB debug card (13-0010) to support IPMI communication. Signed-off-by: Potin Lai <potin.lai.pt@gmail.com> Reviewed-by: Patrick Williams <patrick@stwcx.xyz> Link: https://lore.kernel.org/r/20220810004338.329832-2-potin.lai.pt@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-08-18ARM: dts: aspeed: ast2600-evb: Update I2C devicesJoel Stanley1-5/+16
The AST2600A3 EVB has the following I2C devices: - ADT7490 at 0x2e - EEPROM at 0xa0 - LM75 at 0x9a The bus these devices appear on can be configured by jumpers. The device tree is configured with the buses given by the default jumper settings. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Ryan Chen <ryan_chen@aspeedtech.com> Link: https://lore.kernel.org/r/20220623094717.3873328-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-08-17Change calling conventions for filldir_tAl Viro1-5/+5
filldir_t instances (directory iterators callbacks) used to return 0 for "OK, keep going" or -E... for "stop". Note that it's *NOT* how the error values are reported - the rules for those are callback-dependent and ->iterate{,_shared}() instances only care about zero vs. non-zero (look at emit_dir() and friends). So let's just return bool ("should we keep going?") - it's less confusing that way. The choice between "true means keep going" and "true means stop" is bikesheddable; we have two groups of callbacks - do something for everything in directory, until we run into problem and find an entry in directory and do something to it. The former tended to use 0/-E... conventions - -E<something> on failure. The latter tended to use 0/1, 1 being "stop, we are done". The callers treated anything non-zero as "stop", ignoring which non-zero value did they get. "true means stop" would be more natural for the second group; "true means keep going" - for the first one. I tried both variants and the things like if allocation failed something = -ENOMEM; return true; just looked unnatural and asking for trouble. [folded suggestion from Matthew Wilcox <willy@infradead.org>] Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-17riscv: dts: microchip: correct L2 cache interruptsHeinrich Schuchardt1-1/+1
The "PolarFire SoC MSS Technical Reference Manual" documents the following PLIC interrupts: 1 - L2 Cache Controller Signals when a metadata correction event occurs 2 - L2 Cache Controller Signals when an uncorrectable metadata event occurs 3 - L2 Cache Controller Signals when a data correction event occurs 4 - L2 Cache Controller Signals when an uncorrectable data event occurs This differs from the SiFive FU540 which only has three L2 cache related interrupts. The sequence in the device tree is defined by an enum: enum {         DIR_CORR = 0,         DATA_CORR,         DATA_UNCORR,         DIR_UNCORR, }; So the correct sequence of the L2 cache interrupts is interrupts = <1>, <3>, <4>, <2>; [Conor] This manifests as an unusable system if the l2-cache driver is enabled, as the wrong interrupt gets cleared & the handler prints errors to the console ad infinitum. Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE board") CC: stable@vger.kernel.org # 5.15: e35b07a7df9b: riscv: dts: microchip: mpfs: Group tuples in interrupt properties Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2022-08-17arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: add alternate touchpadJohan Hovold1-0/+16
Add support for the alternate (second-source) touchpad found on some X13s laptops. Note that alternate touchpad is kept disabled for now. The boot firmware should determine which device is actually populated and enable only the corresponding node. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-8-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: mark HID wakeup sourcesJohan Hovold1-0/+4
The touchpad and keyboard can wake the system from suspend so declare them as wakeup sources. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-7-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: move HID pin configJohan Hovold1-2/+14
The HID pin configurations belong in the HID nodes rather than i2c bus node. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-6-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: disable touchscreen pull-upJohan Hovold1-1/+1
The (optional) touchscreen interrupt line has an external pull-up so disable the internal one as is done for the keyboard and touchpad. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-5-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-crd: mark HID wakeup sourcesJohan Hovold1-0/+4
The touchpad and keyboard can wake the system from suspend so declare them as wakeup sources. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-4-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-crd: move HID pin configJohan Hovold1-2/+14
The HID pin configurations belong in the HID nodes rather than i2c bus node. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-3-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sc8280xp-crd: disable touchscreen pull-upJohan Hovold1-1/+1
The touchscreen interrupt line has an external pull-up so disable the internal one as is done for the keyboard and touchpad. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-2-johan+linaro@kernel.org
2022-08-17arm64: dts: qcom: sdm845: add LLCC BWMONKrzysztof Kozlowski1-0/+37
The SDM845 comes with few instances of Bandwidth Monitor. The already supported one monitors traffic between CPU and Last Level Cache Controller (LLCC) and in downstream sources is called BWMON v4 (or v4 of register layout). SDM845 also has also BWMON instance measuring traffic between LLCC and memory with different register layout: called v5. Cc: Rajendra Nayak <quic_rjendra@quicinc.com> Cc: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220728113748.170548-12-krzysztof.kozlowski@linaro.org
2022-08-17arm64: dts: qcom: sdm845: narrow LLCC address spaceKrzysztof Kozlowski1-1/+1
The Last Level Cache Controller (LLCC) device does not need to access entire LLCC address space. Currently driver uses only hardware info and status registers which both reside in LLCC0_COMMON range (offset 0x30000, size 0x1000). Narrow the address space to allow binding other drivers to rest of LLCC address space. Cc: Rajendra Nayak <quic_rjendra@quicinc.com> Cc: Sibi Sankar <quic_sibis@quicinc.com> Reported-by: Steev Klimaszewski <steev@kali.org> Suggested-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220728113748.170548-11-krzysztof.kozlowski@linaro.org
2022-08-17Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds1-1/+1
Pull virtio fixes from Michael Tsirkin: "Most notably this drops the commits that trip up google cloud (turns out, any legacy device). Plus a kerneldoc patch" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio: kerneldocs fixes and enhancements virtio: Revert "virtio: find_vqs() add arg sizes" virtio_vdpa: Revert "virtio_vdpa: support the arg sizes of find_vqs()" virtio_pci: Revert "virtio_pci: support the arg sizes of find_vqs()" virtio-mmio: Revert "virtio_mmio: support the arg sizes of find_vqs()" virtio: Revert "virtio: add helper virtio_find_vqs_ctx_size()" virtio_net: Revert "virtio_net: set the default max ring size by find_vqs()"
2022-08-17arm64: adjust KASLR relocation after ARCH_RANDOM removalLukas Bulwahn1-5/+3
Commit aacd149b6238 ("arm64: head: avoid relocating the kernel twice for KASLR") adds the new file arch/arm64/kernel/pi/kaslr_early.c with a small code part guarded by '#ifdef CONFIG_ARCH_RANDOM'. Concurrently, commit 9592eef7c16e ("random: remove CONFIG_ARCH_RANDOM") removes the config CONFIG_ARCH_RANDOM and turns all '#ifdef CONFIG_ARCH_RANDOM' code parts into unconditional code parts, which is generally safe to do. Remove a needless ifdef guard after the ARCH_RANDOM removal. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220721100433.18286-1-lukas.bulwahn@gmail.com Signed-off-by: Will Deacon <will@kernel.org>
2022-08-17arm64: Fix match_list for erratum 1286807 on Arm Cortex-A76Zenghui Yu1-0/+2
Since commit 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX gold CPUs"), we failed to detect erratum 1286807 on Cortex-A76 because its entry in arm64_repeat_tlbi_list[] was accidently corrupted by this commit. Fix this issue by creating a separate entry for Kryo4xx Gold. Fixes: 51f559d66527 ("arm64: Enable repeat tlbi workaround on KRYO4XX gold CPUs") Cc: Shreyas K K <quic_shrekk@quicinc.com> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220809043848.969-1-yuzenghui@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2022-08-17ARM: dts: imx6dl-yapp4: Bind the backlight controller to the LCD panelMichal Vokáč1-0/+1
Add connection between the backlight controller and LCD panel. With that the backlight is automatically switched on when the panel is on or switched off when the panel is blanked. Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.