aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-04-14arm64: Improve HAVE_DYNAMIC_FTRACE_WITH_REGS selection for clangNathan Chancellor1-2/+11
Will and Anders reported that using just 'CC=clang' with CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y would result in an error while linking: aarch64-linux-gnu-ld: .init.data has both ordered [`__patchable_function_entries' in init/main.o] and unordered [`.meminit.data' in mm/sparse.o] sections aarch64-linux-gnu-ld: final link failed: bad value This error was exposed by commit f12b034afeb3 ("scripts/Makefile.clang: default to LLVM_IAS=1") in combination with binutils older than 2.36. When '-fpatchable-function-entry' was implemented in LLVM, two code paths were added for adding the section attributes, one for the integrated assembler and another for GNU as, due to binutils deficiencies at the time. If the integrated assembler was used, attributes that GNU ld < 2.36 could not handle were added, presumably with the assumption that use of the integrated assembler meant the whole LLVM stack was being used, namely ld.lld. Prior to the kernel change previously mentioned, that assumption was valid, as there were three commonly used combinations of tools for compiling, assembling, and linking respectively: $ make CC=clang (clang, GNU as, GNU ld) $ make LLVM=1 (clang, GNU as, ld.lld) $ make LLVM=1 LLVM_IAS=1 (clang, integrated assembler, ld.lld) After the default switch of the integrated assembler, the second and third commands become equivalent and the first command means "clang, integrated assembler, and GNU ld", which was not a combination that was considered when the aforementioned LLVM change was implemented. It is not possible to go back and fix LLVM, as this change was implemented in the 10.x series, which is no longer supported. To workaround this on the kernel side, split out the selection of HAVE_DYNAMIC_FTRACE_WITH_REGS to two separate configurations, one for GCC and one for clang. The GCC config inherits the '-fpatchable-function-entry' check. The Clang config does not it, as '-fpatchable-function-entry' is always available for LLVM 11.0.0 and newer, which is the supported range of versions for the kernel. The Clang config makes sure that the user is using GNU as or the integrated assembler with ld.lld or GNU ld 2.36 or newer, which will avoid the error above. Link: https://github.com/ClangBuiltLinux/linux/issues/1507 Link: https://github.com/ClangBuiltLinux/linux/issues/788 Link: https://lore.kernel.org/YlCA5PoIjF6nhwYj@dev-arch.thelio-3990X/ Link: https://sourceware.org/bugzilla/show_bug.cgi?id=26256 Link: https://github.com/llvm/llvm-project/commit/7fa5290d5bd5632d7a36a4ea9f46e81e04fb819e Link: https://github.com/llvm/llvm-project/commit/853a2649160c1c80b9bbd38a20b53ca8fab704e8 Reported-by: Anders Roxell <anders.roxell@linaro.org> Reported-by: Will Deacon <will@kernel.org> Tested-by: Will Deacon <will@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220413181420.3522187-1-nathan@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2022-04-14ARM: dts: logicpd-som-lv: Fix wrong pinmuxing on OMAP35Adam Ford3-15/+30
The pinout of the OMAP35 and DM37 variants of the SOM-LV are the same, but the macros which define the pinmuxing are different between OMAP3530 and DM3730. The pinmuxing was correct for for the DM3730, but wrong for the OMAP3530. Since the boot loader was correctly pin-muxing the pins, this was not obvious. As the bootloader not guaranteed to pinmux all the pins any more, this causes an issue, so the pinmux needs to be moved from a common file to their respective board files. Fixes: f8a2e3ff7103 ("ARM: dts: Add minimal support for LogicPD OMAP35xx SOM-LV devkit") Signed-off-by: Adam Ford <aford173@gmail.com> Message-Id: <20220303171818.11060-1-aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-04-14ARM: dts: am3517-evm: Fix misc pinmuxingAdam Ford2-5/+49
The bootloader for the AM3517 has previously done much of the pin muxing, but as the bootloader is moving more and more to a model based on the device tree, it may no longer automatically mux the pins, so it is necessary to add the pinmuxing to the Linux device trees so the respective peripherals can remain functional. Fixes: 6ed1d7997561 ("ARM: dts: am3517-evm: Add support for UI board and Audio") Signed-off-by: Adam Ford <aford173@gmail.com> Message-Id: <20220226214820.747847-1-aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-04-14ARM: dts: am33xx-l4: Add missing touchscreen clock propertiesMiquel Raynal1-0/+2
When adding support for TI magadc (Magnetic Stripe Reader and ADC), the MFD driver common to the touchscreen and the ADC got updated to ease the insertion of a new DT node for the ADC, with its own compatible, clocks, etc. Commit 235a96e92c16 ("mfd: ti_am335x_tscadc: Don't search the tree for our clock") removed one compatible specific information which was the clock name, because the clock was looked up from scratch in the DT while this hardware block was only fed by a single clock, already defined and properly filled in the DT. Problem is, this change was only validated with an am437x-based board, where the clocks are effectively correctly defined and referenced. But on am33xx, the ADC clock is also correctly defined but is not referenced with a clock phandle as it ought to be. The touchscreen bindings clearly state that the clocks/clock-names properties are mandatory, but they have been forgotten in one DTSI. This was probably not noticed in the first place because of the clock actually existing and the clk_get() call going through all the tree anyway. Add the missing clock phandles in the am33xx touchscreen description. Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Fixes: 235a96e92c16 ("mfd: ti_am335x_tscadc: Don't search the tree for our clock") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: H. Nikolaus Schaller <hns@goldelico.com> Message-Id: <20220314163445.79807-1-miquel.raynal@bootlin.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-04-14ARM: dts: Fix mmc order for omap3-gta04H. Nikolaus Schaller1-0/+2
Commit a1ebdb374199 ("ARM: dts: Fix swapped mmc order for omap3") introduces general mmc aliases. Let's tailor them to the need of the GTA04 board which does not make use of mmc2 and mmc3 interfaces. Fixes: a1ebdb374199 ("ARM: dts: Fix swapped mmc order for omap3") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Message-Id: <dc9173ee3d391d9e92b7ab8ed4f84b29f0a21c83.1646744420.git.hns@goldelico.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2022-04-14arm64: dts: juno: add CTI entries to device treeMike Leach8-5/+302
Add Coresight Cross Trigger Interface(CTI) entries to the device tree for all the Juno variants. Link: https://lore.kernel.org/r/20220413214925.30359-1-mike.leach@linaro.org Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-04-14arm64: dts: juno: Fix SCMI power domain IDs for ETF and CS funnelSudeep Holla2-4/+4
The SCMI power domain ID for all the coresight components is 8 while the previous/older SCPI domain was 0. When adding SCMI variant, couple of instances retained SCPI domain ID by mistake. Fix the same by using the correct SCMI power domain ID of 8. Link: https://lore.kernel.org/r/20220413093547.1699535-1-sudeep.holla@arm.com Fixes: 96bb0954860a ("arm64: dts: juno: Add separate SCMI variants") Cc: Robin Murphy <robin.murphy@arm.com> Reported-by: Mike Leach <Mike.Leach@arm.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-04-14Merge tag 'drm-intel-next-2022-04-13-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie1-0/+1
drm/i915 feature pull for v5.19: Features and functionality: - Add support for new Tile 4 format on DG2 (Stan) - Add support for new CCS clear color compression on DG2 (Mika, Juha-Pekka) - Add support for new render and media compression formats on DG2 (Matt) - Support multiple eDP and LVDS native mode refresh rates (Ville) - Support static DRRS (Ville) - ATS-M platform info (Matt) - RPL-S PCI IDs (Tejas) - Extend DP HDR support to HSW+ (Uma) - Bump ADL-P DMC version to v2.16 (Madhumitha) - Let users disable PSR2 while enabling PSR1 (José) Refactoring and cleanups: - Massive DRRS and panel fixed mode refactoring and cleanups (Ville) - Power well refactoring and cleanup (Imre) - Clean up and refactor crtc readout and compute config (Ville) - Use kernel string helpers (Lucas) - Refactor gmbus pin lookups and allocation (Jani) - PCH display cleanups (Ville) - DPLL and DPLL manager refactoring (Ville) - Include and header refactoring (Jani, Tvrtko) - DMC abstractions (Jani) - Non-x86 build refactoring (Casey) - VBT parsing refactoring (Ville) - Bigjoiner refactoring (Ville) - Optimize plane, pfit, scaler, etc. programming using unlocked writes (Ville) - Split several register writes in commit to noarm+arm pairs (Ville) - Clean up SAGV handling (Ville) - Clean up bandwidth and ddb allocation (Ville) - FBC cleanups (Ville) Fixes: - Fix native HDMI and DP HDMI DFP clock limits on deep color/4:2:0 (Ville) - Fix DMC firmware platform check (Lucas) - Fix cursor coordinates on bigjoiner secondary (Ville) - Fix MSO vs. bigjoiner timing confusion (Ville) - Fix ADL-P eDP voltage swing (José) - Fix VRR capability property update (Manasi) - Log DG2 SNPS PHY calibration errors (Matt, Lucas) - Fix PCODE request status checks (Stan) - Fix uncore unclaimed access warnings (Lucas) - Fix VBT new max TMDS clock parsing (Shawn) - Fix ADL-P non-existent underrun recovery (Swathi Dhanavanthri) - Fix ADL-N stepping info (Tejas) - Fix DPT mapping flags to contiguous (Stan) - Fix DG2 max display bandwidth (Vinod) - Fix DP low voltage SKU checks (Ankit) - Fix RPL-S VT-d translation enable via quirk (Tejas) - Fixes to PSR2 (José) - Fix PIPE_MBUS_DBOX_CTL programming (José) - Fix LTTPR capability read/check on DP 1.2 (Imre) - Fix ADL-P register corruption after DDI clock enabling (Imre) - Fix ADL-P MBUS DBOX BW and B credits (Caz) Merges: - Backmerge drm-next (Rodrigo, Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/874k2xgewe.fsf@intel.com
2022-04-13cfi: Use __builtin_function_startSami Tolvanen2-20/+1
Clang 14 added support for the __builtin_function_start function, which allows us to implement the function_nocfi macro without architecture-specific inline assembly and in a way that also works with static initializers. Change CONFIG_CFI_CLANG to depend on Clang >= 14, define function_nocfi using __builtin_function_start, and remove the arm64 inline assembly implementation. Link: https://github.com/llvm/llvm-project/commit/ec2e26eaf63558934f5b73a6e530edc453cf9508 Link: https://github.com/ClangBuiltLinux/linux/issues/1353 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Will Deacon <will@kernel.org> # arm64 Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220405221618.633743-1-samitolvanen@google.com
2022-04-13mm/usercopy: Check kmap addresses properlyMatthew Wilcox (Oracle)1-0/+1
If you are copying to an address in the kmap region, you may not copy across a page boundary, no matter what the size of the underlying allocation. You can't kmap() a slab page because slab pages always come from low memory. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220110231530.665970-2-willy@infradead.org
2022-04-13ACPI: APEI: Fix missing ERST record idLiu Xinpeng1-5/+3
Read a record is cleared by others, but the deleted record cache entry is still created by erst_get_record_id_next. When next enumerate the records, get the cached deleted record, then erst_read() return -ENOENT and try to get next record, loop back to first ID will return 0 in function __erst_record_id_cache_add_one and then set record_id as APEI_ERST_INVALID_RECORD_ID, finished this time read operation. It will result in read the records just in the cache hereafter. This patch cleared the deleted record cache, fix the issue that "./erst-inject -p" shows record counts not equal to "./erst-inject -n". A reproducer of the problem(retry many times): [root@localhost erst-inject]# ./erst-inject -c 0xaaaaa00011 [root@localhost erst-inject]# ./erst-inject -p rc: 273 rcd sig: CPER rcd id: 0xaaaaa00012 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00013 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00014 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000006 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000007 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000008 [root@localhost erst-inject]# ./erst-inject -p rc: 273 rcd sig: CPER rcd id: 0xaaaaa00012 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00013 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00014 [root@localhost erst-inject]# ./erst-inject -n total error record count: 6 Signed-off-by: Liu Xinpeng <liuxp11@chinatelecom.cn> Reviewed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-13x86/crash: Fix minor typo/bug in debug messageEric DeVolder1-1/+1
The pr_debug() intends to display the memsz member, but the parameter is actually the bufsz member (which is already displayed). Correct this to display memsz value. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20220413164237.20845-2-eric.devolder@oracle.com
2022-04-13KVM: x86: Bail to userspace if emulation of atomic user access faultsSean Christopherson1-1/+1
Exit to userspace when emulating an atomic guest access if the CMPXCHG on the userspace address faults. Emulating the access as a write and thus likely treating it as emulated MMIO is wrong, as KVM has already confirmed there is a valid, writable memslot. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220202004945.2540433-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Use __try_cmpxchg_user() to emulate atomic accessesSean Christopherson1-21/+14
Use the recently introduce __try_cmpxchg_user() to emulate atomic guest accesses via the associated userspace address instead of mapping the backing pfn into kernel address space. Using kvm_vcpu_map() is unsafe as it does not coordinate with KVM's mmu_notifier to ensure the hva=>pfn translation isn't changed/unmapped in the memremap() path, i.e. when there's no struct page and thus no elevated refcount. Fixes: 42e35f8072c3 ("KVM/X86: Use kvm_vcpu_map in emulator_cmpxchg_emulated") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220202004945.2540433-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bitsSean Christopherson1-37/+1
Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing "random" pfns for pretty much any other VM_PFNMAP case. Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs") Debugged-by: Tadeusz Struk <tadeusz.struk@linaro.org> Tested-by: Tadeusz Struk <tadeusz.struk@linaro.org> Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220202004945.2540433-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13x86/uaccess: Implement macros for CMPXCHG on user addressesPeter Zijlstra1-0/+142
Add support for CMPXCHG loops on userspace addresses. Provide both an "unsafe" version for tight loops that do their own uaccess begin/end, as well as a "safe" version for use cases where the CMPXCHG is not buried in a loop, e.g. KVM will resume the guest instead of looping when emulation of a guest atomic accesses fails the CMPXCHG. Provide 8-byte versions for 32-bit kernels so that KVM can do CMPXCHG on guest PAE PTEs, which are accessed via userspace addresses. Guard the asm_volatile_goto() variation with CC_HAS_ASM_GOTO_TIED_OUTPUT, the "+m" constraint fails on some compilers that otherwise support CC_HAS_ASM_GOTO_OUTPUT. Cc: stable@vger.kernel.org Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220202004945.2540433-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ESPeter Gonda1-2/+7
If an SEV-ES guest requests termination, exit to userspace with KVM_EXIT_SYSTEM_EVENT and a dedicated SEV_TERM type instead of -EINVAL so that userspace can take appropriate action. See AMD's GHCB spec section '4.1.13 Termination Request' for more details. Suggested-by: Sean Christopherson <seanjc@google.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Peter Gonda <pgonda@google.com> Reported-by: kernel test robot <lkp@intel.com> Message-Id: <20220407210233.782250-1-pgonda@google.com> [Add documentatino. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: nVMX: Clear IDT vectoring on nested VM-Exit for double/triple faultSean Christopherson2-4/+33
Clear the IDT vectoring field in vmcs12 on next VM-Exit due to a double or triple fault. Per the SDM, a VM-Exit isn't considered to occur during event delivery if the exit is due to an intercepted double fault or a triple fault. Opportunistically move the default clearing (no event "pending") into the helper so that it's more obvious that KVM does indeed handle this case. Note, the double fault case is worded rather wierdly in the SDM: The original event results in a double-fault exception that causes the VM exit directly. Temporarily ignoring injected events, double faults can _only_ occur if an exception occurs while attempting to deliver a different exception, i.e. there's _always_ an original event. And for injected double fault, while there's no original event, injected events are never subject to interception. Presumably the SDM is calling out that a the vectoring info will be valid if a different exit occurs after a double fault, e.g. if a #PF occurs and is intercepted while vectoring #DF, then the vectoring info will show the double fault. In other words, the clause can simply be read as: The VM exit is caused by a double-fault exception. Fixes: 4704d0befb07 ("KVM: nVMX: Exiting from L2 to L1") Cc: Chenyi Qiang <chenyi.qiang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220407002315.78092-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: nVMX: Leave most VM-Exit info fields unmodified on failed VM-EntrySean Christopherson1-5/+10
Don't modify vmcs12 exit fields except EXIT_REASON and EXIT_QUALIFICATION when performing a nested VM-Exit due to failed VM-Entry. Per the SDM, only the two aformentioned fields are filled and "All other VM-exit information fields are unmodified". Fixes: 4704d0befb07 ("KVM: nVMX: Exiting from L2 to L1") Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220407002315.78092-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2Sean Christopherson2-6/+0
Remove WARNs that sanity check that KVM never lets a triple fault for L2 escape and incorrectly end up in L1. In normal operation, the sanity check is perfectly valid, but it incorrectly assumes that it's impossible for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through KVM_RUN (which guarantees kvm_check_nested_state() will see and handle the triple fault). The WARN can currently be triggered if userspace injects a machine check while L2 is active and CR4.MCE=0. And a future fix to allow save/restore of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn't lost on migration, will make it trivially easy for userspace to trigger the WARN. Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is tempting, but wrong, especially if/when the request is saved/restored, e.g. if userspace restores events (including a triple fault) and then restores nested state (which may forcibly leave guest mode). Ignoring the fact that KVM doesn't currently provide the necessary APIs, it's userspace's responsibility to manage pending events during save/restore. ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Modules linked in: kvm_intel kvm irqbypass CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Call Trace: <TASK> vmx_leave_nested+0x30/0x40 [kvm_intel] vmx_set_nested_state+0xca/0x3e0 [kvm_intel] kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm] kvm_vcpu_ioctl+0x4b9/0x660 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> ---[ end trace 0000000000000000 ]--- Fixes: cb6a32c2b877 ("KVM: x86: Handle triple fault in L2 without killing L1") Cc: stable@vger.kernel.org Cc: Chenyi Qiang <chenyi.qiang@intel.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220407002315.78092-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Use static calls to reduce kvm_pmu_ops overheadLike Xu2-22/+65
Use static calls to improve kvm_pmu_ops performance, following the same pattern and naming scheme used by kvm-x86-ops.h. Here are the worst fenced_rdtsc() cycles numbers for the kvm_pmu_ops functions that is most often called (up to 7 digits of calls) when running a single perf test case in a guest on an ICX 2.70GHz host (mitigations=on): | legacy | static call ------------------------------------------------------------ .pmc_idx_to_pmc | 1304840 | 994872 (+23%) .pmc_is_enabled | 978670 | 1011750 (-3%) .msr_idx_to_pmc | 47828 | 41690 (+12%) .is_valid_msr | 28786 | 30108 (-4%) Signed-off-by: Like Xu <likexu@tencent.com> [sean: Handle static call updates in pmu.c, tweak changelog] Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329235054.3534728-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Move .pmu_ops to kvm_x86_init_ops and tag as __initdataLike Xu6-7/+6
The pmu_ops should be moved to kvm_x86_init_ops and tagged as __initdata. That'll save those precious few bytes, and more importantly make the original ops unreachable, i.e. make it harder to sneak in post-init modification bugs. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Like Xu <likexu@tencent.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329235054.3534728-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Copy kvm_pmu_ops by value to eliminate layer of indirectionLike Xu3-26/+37
Replace the kvm_pmu_ops pointer in common x86 with an instance of the struct to save one pointer dereference when invoking functions. Copy the struct by value to set the ops during kvm_init(). Signed-off-by: Like Xu <likexu@tencent.com> [sean: Move pmc_is_enabled(), make kvm_pmu_ops static] Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329235054.3534728-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86: Move kvm_ops_static_call_update() to x86.cLike Xu2-16/+17
The kvm_ops_static_call_update() is defined in kvm_host.h. That's completely unnecessary, it should have exactly one caller, kvm_arch_hardware_setup(). Move the helper to x86.c and have it do the actual memcpy() of the ops in addition to the static call updates. This will also allow for cleanly giving kvm_pmu_ops static_call treatment. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Like Xu <likexu@tencent.com> [sean: Move memcpy() into the helper and rename accordingly] Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329235054.3534728-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86/mmu: Derive EPT violation RWX bits from EPTE RWX bitsSean Christopherson3-10/+10
Derive the mask of RWX bits reported on EPT violations from the mask of RWX bits that are shoved into EPT entries; the layout is the same, the EPT violation bits are simply shifted by three. Use the new shift and a slight copy-paste of the mask derivation instead of completely open coding the same to convert between the EPT entry bits and the exit qualification when synthesizing a nested EPT Violation. No functional change intended. Cc: SU Hang <darcy.sh@antgroup.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329030108.97341-3-darcy.sh@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: VMX: replace 0x180 with EPT_VIOLATION_* definitionSU Hang2-1/+4
Using self-expressing macro definition EPT_VIOLATION_GVA_VALIDATION and EPT_VIOLATION_GVA_TRANSLATED instead of 0x180 in FNAME(walk_addr_generic)(). Signed-off-by: SU Hang <darcy.sh@antgroup.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220329030108.97341-2-darcy.sh@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13x86/kvm: Don't waste kvmclock memory if there is nopv parameterWanpeng Li1-1/+1
When the "nopv" command line parameter is used, it should not waste memory for kvmclock. Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Message-Id: <1646727529-11774-1-git-send-email-wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13kvm: vmx: remove redundant parenthesesPeng Hao1-1/+1
Remove redundant parentheses. Signed-off-by: Peng Hao <flyingpeng@tencent.com> Message-Id: <20220228030902.88465-1-flyingpeng@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13kvm: x86: Adjust the location of pkru_mask of kvm_mmu to reduce memoryPeng Hao1-8/+9
Adjust the field pkru_mask to the back of direct_map to make up 8-byte alignment.This reduces the size of kvm_mmu by 8 bytes. Signed-off-by: Peng Hao <flyingpeng@tencent.com> Message-Id: <20220228030749.88353-1-flyingpeng@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13KVM: x86/xen: Remove the redundantly included header file lapic.hLike Xu1-1/+0
The header lapic.h is included more than once, remove one of them. Signed-off-by: Like Xu <likexu@tencent.com> Message-Id: <20220406063715.55625-2-likexu@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13Merge branch 'kvm-older-features' into HEADPaolo Bonzini17-531/+1711
Merge branch for features that did not make it into 5.18: * New ioctls to get/set TSC frequency for a whole VM * Allow userspace to opt out of hypercall patching Nested virtualization improvements for AMD: * Support for "nested nested" optimizations (nested vVMLOAD/VMSAVE, nested vGIF) * Allow AVIC to co-exist with a nested guest running * Fixes for LBR virtualizations when a nested guest is running, and nested LBR virtualization support * PAUSE filtering for nested hypervisors Guest support: * Decoupling of vcpu_is_preempted from PV spinlocks Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-13efi: Save location of EFI confidential computing areaDov Murik1-0/+3
Confidential computing (coco) hardware such as AMD SEV (Secure Encrypted Virtualization) allows a guest owner to inject secrets into the VMs memory without the host/hypervisor being able to read them. Firmware support for secret injection is available in OVMF, which reserves a memory area for secret injection and includes a pointer to it the in EFI config table entry LINUX_EFI_COCO_SECRET_TABLE_GUID. If EFI exposes such a table entry, uefi_init() will keep a pointer to the EFI config table entry in efi.coco_secret, so it can be used later by the kernel (specifically drivers/virt/coco/efi_secret). It will also appear in the kernel log as "CocoSecret=ADDRESS"; for example: [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: CocoSecret=0x7f22e680 SMBIOS=0x7f541000 ACPI=0x7f77e000 ACPI 2.0=0x7f77e014 MEMATTR=0x7ea0c018 The new functionality can be enabled with CONFIG_EFI_COCO_SECRET=y. Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://lore.kernel.org/r/20220412212127.154182-2-dovmurik@linux.ibm.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-04-13ARM: dts: at91: fix pinctrl phandlesClaudiu Beznea2-6/+6
Commit bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") introduces pinctrl phandles for pins used by individual controllers to avoid failures due to commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges"). For SPI controllers available on SAMA5D4 and SAMA5D3 some of the pins are defined in SoC specific dtsi on behalf of pinctrl-0. Adding extra pinctrl phandles on board specific dts also on behalf of pinctrl-0 overwrite the pinctrl-0 phandle specified in SoC specific dtsi. Thus add the board specific pinctrl to pinctrl-1. Fixes: bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") Depends-on: 5c8b49852910 ("ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle name") Reported-by: Ajay Kathat <ajay.kathat@microchip.com> Co-developed-by: Ajay Kathat <ajay.kathat@microchip.com> Signed-off-by: Ajay Kathat <ajay.kathat@microchip.com> Tested-by: Ajay Kathat <ajay.kathat@microchip.com> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220331141323.194355-2-claudiu.beznea@microchip.com
2022-04-13ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle nameClaudiu Beznea1-2/+2
Pinctrl phandle is for spi1 so rename it to reflect this. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220331141323.194355-1-claudiu.beznea@microchip.com
2022-04-13ARM: dts: at91: Describe regulators on at91sam9g20ekMark Brown1-0/+37
The at91sam9g20ek has no software controllable regulators, only some fixed discrete regulators, but they are there and currently the wm8731 driver does try to use them. Show the supplies in the DT and map them for the wm8731 so things start up cleanly. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220404102806.581374-3-broonie@kernel.org
2022-04-13ARM: dts: at91: Map MCLK for wm8731 on at91sam9g20ekMark Brown1-0/+6
The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the PCK0 output of the SoC and is expected to be set to 12MHz. Previously this was mapped using pre-common clock API calls in the audio machine driver but the conversion to the common clock framework broke that so describe things in the DT instead. Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220404102806.581374-2-broonie@kernel.org
2022-04-13ARM: dts: at91: Fix boolean properties with valuesRob Herring2-2/+2
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter. It may have been intended that 0 values are false, but there is no change in behavior with this patch. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/Yk3leykDEKGBN8rk@robh.at.kernel.org
2022-04-13ARM: dts: at91: use generic node name for dataflashKrzysztof Kozlowski8-9/+9
The node names should be generic, so use "flash" for dataflash nodes and for cfi-flash. Suggested-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220412105013.249793-1-krzysztof.kozlowski@linaro.org
2022-04-13ARM: dts: at91: align SPI NOR node name with dtschemaKrzysztof Kozlowski12-12/+12
The node names should be generic and SPI NOR dtschema expects "flash". Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220407143223.295344-1-krzysztof.kozlowski@linaro.org
2022-04-13ARM: dts: at91: sama7g5ek: Align the impedance of the QSPI0's HSIO and PCB linesTudor Ambarus1-1/+1
The impedance of the QSPI PCB lines on the sama7g5ek is 50 Ohms. Align the output impedance of the QSPI0 HSIOs by setting a medium drive strength which corresponds to an impedance of 56 Ohms when VDD is in the 3.0V - 3.6V range. The high drive strength setting corresponds to an output impedance of 42 Ohms on the QSPI0 HSIOs. Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220406130505.422042-1-tudor.ambarus@microchip.com
2022-04-13ARM: dts: at91: sama7g5ek: enable pull-up on flexcom3 console linesEugen Hristev1-1/+1
Flexcom3 is used as board console serial. There are no pull-ups on these lines on the board. This means that if a cable is not connected (that has pull-ups included), stray characters could appear on the console as the floating pins voltage levels are interpreted as incoming characters. To avoid this problem, enable the internal pull-ups on these lines. Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220307113827.2419331-1-eugen.hristev@microchip.com
2022-04-13x86/apic: Clarify i82489DX bit overlap in APIC_LVT0Thomas Gleixner2-7/+10
Daniel stumbled over the bit overlap of the i82498DX external APIC and the TSC deadline timer configuration bit in modern APICs, which is neither documented in the code nor in the current SDM. Maciej provided links to the original i82489DX/486 documentation. See Link. Remove the i82489DX macro maze, use a i82489DX specific define in the apic code and document the overlap in a comment. Reported-by: Daniel Vacek <neelx@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/87ee22f3ci.ffs@tglx
2022-04-13ARM: dts: at91: sama7g5: Swap `rx` and `tx` for `i2c` nodesSergiu Moga1-9/+9
Swap `rx` and `tx` for the `dma-names` property of the `i2c` nodes in order to maintain consistency across Microchip/Atmel SoC files. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220310114553.184763-2-sergiu.moga@microchip.com
2022-04-13x86/ACPI: Preserve ACPI-table override during hibernationAmadeusz Sławiński1-1/+1
When overriding NHLT ACPI-table tests show that on some platforms there is problem that NHLT contains garbage after hibernation/resume cycle. Problem stems from the fact that ACPI override performs early memory allocation using memblock_phys_alloc_range() in memblock_phys_alloc_range(). This memory block is later being marked as ACPI memory block in arch_reserve_mem_area(). Later when memory areas are considered for hibernation it is being marked as nosave in e820__register_nosave_regions(). Fix this by marking ACPI override memory area as ACPI NVS (Non-Volatile-Sleeping), which according to specification needs to be saved on entering S4 and restored when leaving and is implemented as such in kernel. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-04-13arm64: dts: renesas: rzg2ul-smarc-som: Enable Ethernet on SMARC platformBiju Das2-1/+98
Enable Ethernet{0,1} interfaces on RZ/G2UL SMARC EVK. Ethernet0 pins are muxed with CAN0, CAN1, SSI1 and RSPI1 pins and Ethernet0 device selection is based on the SW1[3] switch position. Set SW1[3] to position OFF for selecting CAN0, CAN1, SSI1 and RSPI1. Set SW1[3] to position ON for selecting Ethernet0. This patch disables Ethernet0 on RZ/G2UL SMARC platform by default. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-8-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-04-13arm64: dts: renesas: rzg2ul-smarc-som: Enable eMMC on SMARC platformBiju Das2-0/+112
RZ/G2UL SoM has both 64GB eMMC and microSD connected to SDHI0. Both these interfaces are mutually exclusive and the SD0 device selection is based on SW1[2] on SoM module. Set SW1[2] to position OFF for selecting eMMC Set SW1[2] to position ON for selecting microSD This patch enables eMMC on RZ/G2UL SMARC platform by default. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-7-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-04-13arm64: dts: renesas: rzg2ul-smarc: Enable microSD on SMARC platformBiju Das4-11/+63
Enable the microSD card slot connected to SDHI1 on the RZ/G2UL SMARC platform by removing the sdhi1 override which disabled it, and by adding the necessary pinmux required for SDHI1. This patch also adds gpios property to vccq_sdhi1 regulator. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-6-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-04-13arm64: dts: renesas: r9a07g043: Add GbEthernet nodesBiju Das1-0/+40
Add Gigabit Ethernet{0,1} nodes to SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-5-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-04-13arm64: dts: renesas: r9a07g043: Add SDHI nodesBiju Das1-2/+24
Add SDHI{0, 1} nodes to RZ/G2UL SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-04-13arm64: dts: renesas: rzg2ul-smarc: Add scif0 and audio clk pinsBiju Das2-5/+25
Add scif0 and audio clk pins to soc pinctrl dtsi and drop deleting the pinctrl-0 and pinctrl-names properties for scif0 node so that we now actually make use of these properties for scif0. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220402081328.26292-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>