summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2022-03-01s390/ftrace: fix ftrace_caller/ftrace_regs_caller generationHeiko Carstens
ftrace_caller was used for both ftrace_caller and ftrace_regs_caller, which means that the target address of the hotpatch trampoline was never updated. With commit 894979689d3a ("s390/ftrace: provide separate ftrace_caller/ftrace_regs_caller implementations") a separate ftrace_regs_caller entry point was implemeted, however it was forgotten to implement the necessary changes for ftrace_modify_call and ftrace_make_call, where the branch target has to be modified accordingly. Therefore add the missing code now. Fixes: 894979689d3a ("s390/ftrace: provide separate ftrace_caller/ftrace_regs_caller implementations") Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2022-03-01s390/setup: preserve memory at OLDMEM_BASE and OLDMEM_SIZEAlexander Egorenkov
We need to preserve the values at OLDMEM_BASE and OLDMEM_SIZE which are used by zgetdump in case when kdump crashes. In that case zgetdump will attempt to read OLDMEM_BASE and OLDMEM_SIZE in order to find out where the memory range [0 - OLDMEM_SIZE] belonging to the production kernel is. Fixes: f1a546947431 ("s390/setup: don't reserve memory that occupied decompressor's head") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2022-03-01Merge tag 'qcom-drivers-for-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers Qualcomm driver updates for v5.18 This refactors the Qualcomm mdt file loader, to partially decouple it from the SCM peripheral-authentication-service. This is needed as newer platforms, such as the Qualcomm SM8450, require the metadata to remain accessible to TrustZone during a longer time. This is followed by the introduction of remoteproc drivers for SM8450 (Snapdragon 8 Gen 1). It changes the way hardware version differences are handled in the LLCC driver and introduces support for Qualcomm SM8450. While updating the dt binding for LLCC it also introduces the missing SM8350 compatible. The ocmem and aoss drivers gains missing put_device() calls and rpmpd gains a missing check for kcalloc() failure. The SPM driver is updated to avoid instantiating the SPM cpuidle devices if the CPUs aren't controlled by SPM, such as when Snapdragon 8916 operates in 32-bit mode without PSCI. The RPM power-domain driver gains MSM8226 support. Lastly the socinfo driver gains knowledge about a few new SoCs and PMICs. * tag 'qcom-drivers-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (37 commits) soc: qcom: rpmpd: Add MSM8226 support dt-bindings: power: rpmpd: Add MSM8226 to rpmpd binding soc: qcom: mdt_loader: Fix split-firmware condition dt-bindings: arm: msm: Add LLCC compatible for SM8450 dt-bindings: arm: msm: Add LLCC compatible for SM8350 soc: qcom: llcc: Add configuration data for SM8450 SoC soc: qcom: llcc: Update register offsets for newer LLCC HW soc: qcom: llcc: Add missing llcc configuration data soc: qcom: llcc: Add write-cache cacheable support soc: qcom: llcc: Update the logic for version info extraction soc: qcom: llcc: Add support for 16 ways of allocation soc: qcom: socinfo: Add some more PMICs and SoCs firmware: qcom: scm: Add support for MC boot address API firmware: qcom: scm: Drop cpumask parameter from set_boot_addr() firmware: qcom: scm: Simplify set_cold/warm_boot_addr() cpuidle: qcom-spm: Check if any CPU is managed by SPM remoteproc: qcom: pas: Add SM8450 remoteproc support dt-bindings: remoteproc: qcom: pas: Add SM8450 PAS compatibles remoteproc: qcom: pas: Carry PAS metadata context soc: qcom: mdt_loader: Extract PAS operations ... Link: https://lore.kernel.org/r/20220301042055.1804859-1-bjorn.andersson@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'qcom-arm64-defconfig-for-5.17' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM64 defconfig updates for v5.17 This enables GCC, TLMM pinctrl and the main interconnect provider for the SM8450 platform. * tag 'qcom-arm64-defconfig-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Add SM8450 icc configs arm64: defconfig: Add SM8450 pinctrl config arm64: defconfig: Add SM8450 GCC config Link: https://lore.kernel.org/r/20211222152219.3752973-1-bjorn.andersson@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01KVM: SVM: Disable preemption across AVIC load/put during APICv refreshSean Christopherson
Disable preemption when loading/putting the AVIC during an APICv refresh. If the vCPU task is preempted and migrated ot a different pCPU, the unprotected avic_vcpu_load() could set the wrong pCPU in the physical ID cache/table. Pull the necessary code out of avic_vcpu_{,un}blocking() and into a new helper to reduce the probability of introducing this exact bug a third time. Fixes: df7e4827c549 ("KVM: SVM: call avic_vcpu_load/avic_vcpu_put when enabling/disabling AVIC") Cc: stable@vger.kernel.org Reported-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01mips: ralink: fix a refcount leak in ill_acc_of_setup()Hangyu Hua
of_node_put(np) needs to be called when pdev == NULL. Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-03-01arm64: defconfig: enable the CVP driverDinh Nguyen
Build the CVP driver in the standard arm64 defconfig. Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2022-03-01mips: Implement "current_stack_pointer"Kees Cook
To follow the existing per-arch conventions replace open-coded uses of asm "sp" as "current_stack_pointer". This will let it be used in non-arch places (like HARDENED_USERCOPY). Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Yanteng Si <siyanteng01@gmail.com> Cc: linux-mips@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2022-03-01arm64: dts: n5x: add sdr edac supportDinh Nguyen
The N5X platform has the Synopsys DDR controller the includes an EDAC controller. Add the entry for the controller in the DTS file instead of the base Agilex DTSI because the base Agilex does not have the controller. Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2022-03-01arm64: dts: agilex/stratix10: add clock-names to USB DWC2 nodeKrzysztof Kozlowski
USB DWC2 requires clock-names: arm64/boot/dts/altera/socfpga_stratix10_socdk_nand.dt.yaml: usb@ffb00000: 'clock-names' is a required property Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2022-03-01perf: Add irq and exception return branch typesAnshuman Khandual
This expands generic branch type classification by adding two more entries there in i.e irq and exception return. Also updates the x86 implementation to process X86_BR_IRET and X86_BR_IRQ records as appropriate. This changes branch types reported to user space on x86 platform but it should not be a problem. The possible scenarios and impacts are enumerated here. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1645681014-3346-1-git-send-email-anshuman.khandual@arm.com
2022-03-01perf/x86/intel/uncore: Make uncore_discovery clean for 64 bit addressesSteve Wahl
Support 64-bit BAR size for discovery, and do not truncate return from generic_uncore_mmio_box_ctl() to 32 bits. Signed-off-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20220218175418.421268-1-steve.wahl@hpe.com
2022-03-01KVM: SVM: Exit to userspace on ENOMEM/EFAULT GHCB errorsSean Christopherson
Exit to userspace if setup_vmgexit_scratch() fails due to OOM or because copying data from guest (userspace) memory failed/faulted. The OOM scenario is clearcut, it's userspace's decision as to whether it should terminate the guest, free memory, etc... As for -EFAULT, arguably, any guest issue is a violation of the guest's contract with userspace, and thus userspace needs to decide how to proceed. E.g. userspace defines what is RAM vs. MMIO and communicates that directly to the guest, KVM is not involved in deciding what is/isn't RAM nor in communicating that information to the guest. If the scratch GPA doesn't resolve to a memslot, then the guest is not honoring the memory configuration as defined by userspace. And if userspace unmaps an hva for whatever reason, then exiting to userspace with -EFAULT is absolutely the right thing to do. KVM's ABI currently sucks and doesn't provide enough information to act on the -EFAULT, but that will hopefully be remedied in the future as there are multiple use cases, e.g. uffd and virtiofs truncation, that shouldn't require any work in KVM beyond returning -EFAULT with a small amount of metadata. KVM could define its ABI such that failure to access the scratch area is reflected into the guest, i.e. establish a contract with userspace, but that's undesirable as it limits KVM's options in the future, e.g. in the potential uffd case any failure on a uaccess needs to kick out to userspace. KVM does have several cases where it reflects these errors into the guest, e.g. kvm_pv_clock_pairing() and Hyper-V emulation, but KVM would preferably "fix" those instead of propagating the falsehood that any memory failure is the guest's fault. Lastly, returning a boolean as an "error" for that a helper that isn't named accordingly never works out well. Fixes: ad5b353240c8 ("KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure") Cc: Alper Gun <alpergun@google.com> Cc: Peter Gonda <pgonda@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220225205209.3881130-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01Merge tag 'mvebu-arm-5.18-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/soc mvebu arm for 5.18 (part 1) gpio clean-up for Orion * tag 'mvebu-arm-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: orion/gpio: Get rid of unused first parameter in orion_gpio_init() Link: https://lore.kernel.org/r/87sfs1zrfn.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'mvebu-dt-5.18-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/dt mvebu dt for 5.18 (part 1) Add new 2 bays NAS: - Ctera C200 V1 (kirkwood based) - Ctera C200 V2 (armada-370 based) Add support for PCIe legacy INTx interrupts on Armada 385 Add PCIe proprty to limit the power on miniPCIe slots in Turris Omnia * tag 'mvebu-dt-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: dts: turris-omnia: Set PCIe slot-power-limit-milliwatt properties ARM: dts: mvebu: Add Ctera C-200 V2 board ARM: dts: kirkwood: Add Ctera C-200 V1 board dt-bindings: vendor-prefixes: Add Ctera Networks ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts Link: https://lore.kernel.org/r/87pmn5zrd0.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'mvebu-dt64-5.18-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/dt mvebu dt64 for 5.18 (part 1) Add PCIe clock resource for Armada 37xx * tag 'mvebu-dt64-5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: arm64: dts: marvell: armada-37xx: Add clock to PCIe node Link: https://lore.kernel.org/r/87v8wxzrlo.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'v5.17-next-dts32' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/dt - add initial support for mt6582 and Prestigio PMT5008 3G tablet - add basic support for Airoha EN7523 * tag 'v5.17-next-dts32' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: ARM: dts: add GPIO support for Airoha EN7523 ARM: Add basic support for Airoha EN7523 SoC dt-bindings: arm: airoha: Add binding for EN7523 SoC and EVB dt-bindings: Add vendor prefix for Airoha dt-bindings: mediatek: Adds a DT binding documentation for the MT6582 SoC ARM: dts: Add initial support for Prestigio PMT5008 3G tablet ARM: dts: Add initial support for Mediatek mt6582 Link: https://lore.kernel.org/r/3974dc7e-4185-4d88-ab5b-031a7d24214d@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'v5.17-next-dts64' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/dt mt8192 - add clocks to the devices - add watchdog node - add power domain controller node mt8183: - add pmic (mt6358) key board node - add JPEG enconder node mt7986: - update memory node - add clock controller for mt7986a version * tag 'v5.17-next-dts64' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: arm64: dts: mediatek: update mt7986b memory node arm64: dts: mediatek: update mt7986a memory node arm64: dts: mediatek: add clock support for mt7986a arm64: dts: mediatek: Add mt8192 power domains controller arm64: dts: mt6358: add mt6358-keys node arm64: dts: mt8183: add jpeg enc node for mt8183 arm64: dts: mt8192: Add watchdog node arm64: dts: mediatek: Correct system timer clock of MT8192 arm64: dts: mediatek: Correct I2C clock of MT8192 arm64: dts: mediatek: Correct Nor Flash clock of MT8192 arm64: dts: mediatek: Correct SPI clock of MT8192 arm64: dts: mediatek: Correct uart clock of MT8192 Link: https://lore.kernel.org/r/c2064dcc-acdc-c86b-5ef7-cb8e7ae3122f@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01KVM: WARN if is_unsync_root() is called on a root without a shadow pageSean Christopherson
WARN and bail if is_unsync_root() is passed a root for which there is no shadow page, i.e. is passed the physical address of one of the special roots, which do not have an associated shadow page. The current usage squeaks by without bug reports because neither kvm_mmu_sync_roots() nor kvm_mmu_sync_prev_roots() calls the helper with pae_root or pml4_root, and 5-level AMD CPUs are not generally available, i.e. no one can coerce KVM into calling is_unsync_root() on pml5_root. Note, this doesn't fix the mess with 5-level nNPT, it just (hopefully) prevents KVM from crashing. Cc: Lai Jiangshan <jiangshanlai@gmail.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220225182248.3812651-8-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: s390: Replace KVM_REQ_MMU_RELOAD usage with arch specific requestSean Christopherson
Add an arch request, KVM_REQ_REFRESH_GUEST_PREFIX, to deal with guest prefix changes instead of piggybacking KVM_REQ_MMU_RELOAD. This will allow for the removal of the generic KVM_REQ_MMU_RELOAD, which isn't actually used by generic KVM. No functional change intended. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220225182248.3812651-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86/mmu: Zap only obsolete roots if a root shadow page is zappedSean Christopherson
Zap only obsolete roots when responding to zapping a single root shadow page. Because KVM keeps root_count elevated when stuffing a previous root into its PGD cache, shadowing a 64-bit guest means that zapping any root causes all vCPUs to reload all roots, even if their current root is not affected by the zap. For many kernels, zapping a single root is a frequent operation, e.g. in Linux it happens whenever an mm is dropped, e.g. process exits, etc... Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220225182248.3812651-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: Drop kvm_reload_remote_mmus(), open code request in x86 usersSean Christopherson
Remove the generic kvm_reload_remote_mmus() and open code its functionality into the two x86 callers. x86 is (obviously) the only architecture that uses the hook, and is also the only architecture that uses KVM_REQ_MMU_RELOAD in a way that's consistent with the name. That will change in a future patch, as x86's usage when zapping a single shadow page x86 doesn't actually _need_ to reload all vCPUs' MMUs, only MMUs whose root is being zapped actually need to be reloaded. s390 also uses KVM_REQ_MMU_RELOAD, but for a slightly different purpose. Drop the generic code in anticipation of implementing s390 and x86 arch specific requests, which will allow dropping KVM_REQ_MMU_RELOAD entirely. Opportunistically reword the x86 TDP MMU comment to avoid making references to functions (and requests!) when possible, and to remove the rather ambiguous "this". No functional change intended. Cc: Ben Gardon <bgardon@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Ben Gardon <bgardon@google.com> Message-Id: <20220225182248.3812651-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Invoke kvm_mmu_unload() directly on CR4.PCIDE changeSean Christopherson
Replace a KVM_REQ_MMU_RELOAD request with a direct kvm_mmu_unload() call when the guest's CR4.PCIDE changes. This will allow tweaking the logic of KVM_REQ_MMU_RELOAD to free only obsolete/invalid roots, which is the historical intent of KVM_REQ_MMU_RELOAD. The recent PCIDE behavior is the only user of KVM_REQ_MMU_RELOAD that doesn't mark affected roots as obsolete, needs to unconditionally unload the entire MMU, _and_ affects only the current vCPU. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220225182248.3812651-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86/emulator: Move the unhandled outer privilege level logic of far ↵Hou Wenlong
return into __load_segment_descriptor() Outer-privilege level return is not implemented in emulator, move the unhandled logic into __load_segment_descriptor to make it easier to understand why the checks for RET are incomplete. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com> Message-Id: <5b7188e6388ac9f4567d14eab32db9adf3e00119.1644292363.git.houwenlong.hwl@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86/emulator: Fix wrong privilege check for code segment in ↵Hou Wenlong
__load_segment_descriptor() Code segment descriptor can be loaded by jmp/call/ret, iret and int. The privilege checks are different between those instructions above realmode. Although, the emulator has use x86_transfer_type enumerate to differentiate them, but it is not really used in __load_segment_descriptor(). Note, far jump/call to call gate, task gate or task state segment are not implemented in emulator. As for far jump/call to code segment, if DPL > CPL for conforming code or (RPL > CPL or DPL != CPL) for non-conforming code, it should trigger #GP. The current checks are ok. As for far return, if RPL < CPL or DPL > RPL for conforming code or DPL != RPL for non-conforming code, it should trigger #GP. Outer level return is not implemented above virtual-8086 mode in emulator. So it implies that RPL <= CPL, but the current checks wouldn't trigger #GP if RPL < CPL. As for code segment loading in task switch, if DPL > RPL for conforming code or DPL != RPL for non-conforming code, it should trigger #TS. Since segment selector is loaded before segment descriptor when load state from tss, it implies that RPL = CPL, so the current checks are ok. The only problem in current implementation is missing RPL < CPL check for far return. However, change code to follow the manual is better. Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com> Message-Id: <e01f5ea70fc1f18f23da1182acdbc5c97c0e5886.1644292363.git.houwenlong.hwl@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86/emulator: Defer not-present segment check in ↵Hou Wenlong
__load_segment_descriptor() Per Intel's SDM on the "Instruction Set Reference", when loading segment descriptor, not-present segment check should be after all type and privilege checks. But the emulator checks it first, then #NP is triggered instead of #GP if privilege fails and segment is not present. Put not-present segment check after type and privilege checks in __load_segment_descriptor(). Fixes: 38ba30ba51a00 (KVM: x86 emulator: Emulate task switch in emulator.c) Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com> Message-Id: <52573c01d369f506cadcf7233812427cf7db81a7.1644292363.git.houwenlong.hwl@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Make kvm_lapic_set_reg() a "private" xAPIC helperSean Christopherson
Hide the lapic's "raw" write helper inside lapic.c to force non-APIC code to go through proper helpers when modification the vAPIC state. Keep the read helper visible to outsiders for now, refactoring KVM to hide it too is possible, it will just take more work to do so. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-11-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Treat x2APIC's ICR as a 64-bit register, not two 32-bit regsSean Christopherson
Emulate the x2APIC ICR as a single 64-bit register, as opposed to forking it across ICR and ICR2 as two 32-bit registers. This mirrors hardware behavior for Intel's upcoming IPI virtualization support, which does not split the access. Previous versions of Intel's SDM and AMD's APM don't explicitly state exactly how ICR is reflected in the vAPIC page for x2APIC, KVM just happened to speculate incorrectly. Handling the upcoming behavior is necessary in order to maintain backwards compatibility with KVM_{G,S}ET_LAPIC, e.g. failure to shuffle the 64-bit ICR to ICR+ICR2 and vice versa would break live migration if IPI virtualization support isn't symmetrical across the source and dest. Cc: Zeng Guang <guang.zeng@intel.com> Cc: Chao Gao <chao.gao@intel.com> Cc: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-10-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Add helpers to handle 64-bit APIC MSR read/writesSean Christopherson
Add helpers to handle 64-bit APIC read/writes via MSRs to deduplicate the x2APIC and Hyper-V code needed to service reads/writes to ICR. Future support for IPI virtualization will add yet another path where KVM must handle 64-bit APIC MSR reads/write (to ICR). Opportunistically fix the comment in the write path; ICR2 holds the destination (if there's no shorthand), not the vector. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-9-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Make kvm_lapic_reg_{read,write}() staticSean Christopherson
Make the low level read/write lapic helpers static, any accesses to the local APIC from vendor code or non-APIC code should be routed through proper helpers. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-8-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: WARN if KVM emulates an IPI without clearing the BUSY flagSean Christopherson
WARN if KVM emulates an IPI without clearing the BUSY flag, failure to do so could hang the guest if it waits for the IPI be sent. Opportunistically use APIC_ICR_BUSY macro instead of open coding the magic number, and add a comment to clarify why kvm_recalculate_apic_map() is unconditionally invoked (it's really, really confusing for IPIs due to the existence of fast paths that don't trigger a potential recalc). Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-7-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: SVM: Don't rewrite guest ICR on AVIC IPI virtualization failureSean Christopherson
Don't bother rewriting the ICR value into the vAPIC page on an AVIC IPI virtualization failure, the access is a trap, i.e. the value has already been written to the vAPIC page. The one caveat is if hardware left the BUSY flag set (which appears to happen somewhat arbitrarily), in which case go through the "nodecode" APIC-write path in order to clear the BUSY flag. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-6-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: SVM: Use common kvm_apic_write_nodecode() for AVIC write trapsSean Christopherson
Use the common kvm_apic_write_nodecode() to handle AVIC/APIC-write traps instead of open coding the same exact code. This will allow making the low level lapic helpers inaccessible outside of lapic.c code. Opportunistically clean up the params to eliminate a bunch of svm=>vcpu reflection. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-5-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Use "raw" APIC register read for handling APIC-write VM-ExitSean Christopherson
Use the "raw" helper to read the vAPIC register after an APIC-write trap VM-Exit. Hardware is responsible for vetting the write, and the caller is responsible for sanitizing the offset. This is a functional change, as it means KVM will consume whatever happens to be in the vAPIC page if the write was dropped by hardware. But, unless userspace deliberately wrote garbage into the vAPIC page via KVM_SET_LAPIC, the value should be zero since it's not writable by the guest. This aligns common x86 with SVM's AVIC logic, i.e. paves the way for using the nodecode path to handle APIC-write traps when AVIC is enabled. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: VMX: Handle APIC-write offset wrangling in VMX codeSean Christopherson
Move the vAPIC offset adjustments done in the APIC-write trap path from common x86 to VMX in anticipation of using the nodecode path for SVM's AVIC. The adjustment reflects hardware behavior, i.e. it's technically a property of VMX, no common x86. SVM's AVIC behavior is identical, so it's a bit of a moot point, the goal is purely to make it easier to understand why the adjustment is ok. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220204214205.3306634-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Do not change ICR on write to APIC_SELF_IPIPaolo Bonzini
Emulating writes to SELF_IPI with a write to ICR has an unwanted side effect: the value of ICR in vAPIC page gets changed. The lists SELF_IPI as write-only, with no associated MMIO offset, so any write should have no visible side effect in the vAPIC page. Reported-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: Fix emulation in writing cr8Zhenzhong Duan
In emulation of writing to cr8, one of the lowest four bits in TPR[3:0] is kept. According to Intel SDM 10.8.6.1(baremetal scenario): "APIC.TPR[bits 7:4] = CR8[bits 3:0], APIC.TPR[bits 3:0] = 0"; and SDM 28.3(use TPR shadow): "MOV to CR8. The instruction stores bits 3:0 of its source operand into bits 7:4 of VTPR; the remainder of VTPR (bits 3:0 and bits 31:8) are cleared."; and AMD's APM 16.6.4: "Task Priority Sub-class (TPS)-Bits 3 : 0. The TPS field indicates the current sub-priority to be used when arbitrating lowest-priority messages. This field is written with zero when TPR is written using the architectural CR8 register."; so in KVM emulated scenario, clear TPR[3:0] to make a consistent behavior as in other scenarios. This doesn't impact evaluation and delivery of pending virtual interrupts because processor does not use the processor-priority sub-class to determine which interrupts to delivery and which to inhibit. Sub-class is used by hardware to arbitrate lowest priority interrupts, but KVM just does a round-robin style delivery. Fixes: b93463aa59d6 ("KVM: Accelerated apic support") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220210094506.20181-1-zhenzhong.duan@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01KVM: x86: flush TLB separately from MMU resetPaolo Bonzini
For both CR0 and CR4, disassociate the TLB flush logic from the MMU role logic. Instead of relying on kvm_mmu_reset_context() being a superset of various TLB flushes (which is not necessarily going to be the case in the future), always call it if the role changes but also set the various TLB flush requests according to what is in the manual. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-01powerpc/lib/sstep: Fix build errors with newer binutilsAnders Roxell
Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian 2.37.90.20220207) the following build error shows up: {standard input}: Assembler messages: {standard input}:10576: Error: unrecognized opcode: `stbcx.' {standard input}:10680: Error: unrecognized opcode: `lharx' {standard input}:10694: Error: unrecognized opcode: `lbarx' Rework to add assembler directives [1] around the instruction. The problem with this might be that we can trick a power6 into single-stepping through an stbcx. for instance, and it will execute that in kernel mode. [1] https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code") Cc: stable@vger.kernel.org # v4.14+ Co-developed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220224162215.3406642-3-anders.roxell@linaro.org
2022-03-01powerpc: Fix build errors with newer binutilsAnders Roxell
Building tinyconfig with gcc (Debian 11.2.0-16) and assembler (Debian 2.37.90.20220207) the following build error shows up: {standard input}: Assembler messages: {standard input}:1190: Error: unrecognized opcode: `stbcix' {standard input}:1433: Error: unrecognized opcode: `lwzcix' {standard input}:1453: Error: unrecognized opcode: `stbcix' {standard input}:1460: Error: unrecognized opcode: `stwcix' {standard input}:1596: Error: unrecognized opcode: `stbcix' ... Rework to add assembler directives [1] around the instruction. Going through them one by one shows that the changes should be safe. Like __get_user_atomic_128_aligned() is only called in p9_hmi_special_emu(), which according to the name is specific to power9. And __raw_rm_read*() are only called in things that are powernv or book3s_hv specific. [1] https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo Cc: stable@vger.kernel.org Co-developed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org> [mpe: Make commit subject more descriptive] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220224162215.3406642-2-anders.roxell@linaro.org
2022-03-01powerpc/lib/sstep: Fix 'sthcx' instructionAnders Roxell
Looks like there been a copy paste mistake when added the instruction 'stbcx' twice and one was probably meant to be 'sthcx'. Changing to 'sthcx' from 'stbcx'. Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code") Cc: stable@vger.kernel.org # v4.14+ Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220224162215.3406642-1-anders.roxell@linaro.org
2022-03-01powerpc/Makefile: Don't pass -mcpu=powerpc64 when building 32-bitMichael Ellerman
When CONFIG_GENERIC_CPU=y (true for all our defconfigs) we pass -mcpu=powerpc64 to the compiler, even when we're building a 32-bit kernel. This happens because we have an ifdef CONFIG_PPC_BOOK3S_64/else block in the Makefile that was written before 32-bit supported GENERIC_CPU. Prior to that the else block only applied to 64-bit Book3E. The GCC man page says -mcpu=powerpc64 "[specifies] a pure ... 64-bit big endian PowerPC ... architecture machine [type], with an appropriate, generic processor model assumed for scheduling purposes." It's unclear how that interacts with -m32, which we are also passing, although obviously -m32 is taking precedence in some sense, as the 32-bit kernel only contains 32-bit instructions. This was noticed by inspection, not via any bug reports, but it does affect code generation. Comparing before/after code generation, there are some changes to instruction scheduling, and the after case (with -mcpu=powerpc64 removed) the compiler seems more keen to use r8. Fix it by making the else case only apply to Book3E 64, which excludes 32-bit. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220215112858.304779-1-mpe@ellerman.id.au
2022-03-01powerpc/mm/numa: skip NUMA_NO_NODE onlining in parse_numa_properties()Daniel Henrique Barboza
Executing node_set_online() when nid = NUMA_NO_NODE results in an undefined behavior. node_set_online() will call node_set_state(), into __node_set(), into set_bit(), and since NUMA_NO_NODE is -1 we'll end up doing a negative shift operation inside arch/powerpc/include/asm/bitops.h. This potential UB was detected running a kernel with CONFIG_UBSAN. The behavior was introduced by commit 10f78fd0dabb ("powerpc/numa: Fix a regression on memoryless node 0"), where the check for nid > 0 was removed to fix a problem that was happening with nid = 0, but the result is that now we're trying to online NUMA_NO_NODE nids as well. Checking for nid >= 0 will allow node 0 to be onlined while avoiding this UB with NUMA_NO_NODE. Fixes: 10f78fd0dabb ("powerpc/numa: Fix a regression on memoryless node 0") Reported-by: Ping Fang <pifang@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220224182312.1012527-1-danielhb413@gmail.com
2022-03-01powerpc/interrupt: Remove struct interrupt_stateChristophe Leroy
Since commit ceff77efa4f8 ("powerpc/64e/interrupt: Use new interrupt context tracking scheme") struct interrupt_state has been empty and unused. Remove it. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1d862ce3eab3da6ca7ac47d4a78a18f154462511.1645806970.git.christophe.leroy@csgroup.eu
2022-03-01powerpc/fadump: register for fadump as early as possibleHari Bathini
Crash recovery (fadump) is setup in the userspace by some service. This service rebuilds initrd with dump capture capability, if it is not already dump capture capable before proceeding to register for firmware assisted dump (echo 1 > /sys/kernel/fadump/registered). But arming the kernel with crash recovery support does not have to wait for userspace configuration. So, register for fadump while setting it up itself. This can at worst lead to a scenario, where /proc/vmcore is ready afer crash but the initrd does not know how/where to offload it, which is always better than not having a /proc/vmcore at all due to incomplete configuration in the userspace at the time of crash. Commit 0823c68b054b ("powerpc/fadump: re-register firmware-assisted dump if already registered") ensures this change does not break userspace. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> [mpe: Reword comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220201105305.155511-1-hbathini@linux.ibm.com
2022-03-01ARM: mstar: Select HAVE_ARM_ARCH_TIMERDaniel Palmer
The mstar SoCs have an arch timer but HAVE_ARM_ARCH_TIMER wasn't selected. If MSC313E_TIMER isn't selected then the kernel gets stuck at boot because there are no timers available. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/r/20220301104349.3040422-1-daniel@0x0f.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01ARM: dts: turris-omnia: Set PCIe slot-power-limit-milliwatt propertiesPali Rohár
All 3 miniPCIe slots in Turris Omnia are designed for 10 W. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-03-01Merge tag 'v5.17-next-defconfig' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/defconfig - Enable Airoha SoC on armv7 config. - Enable CPU freq for arm64 based SoCs. - Enable PMIC based (mt6397) RTC for mt8173 * tag 'v5.17-next-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: ARM: multi_v7_defconfig: Add support for Airoha EN7523 SoC arm64: defconfig: Enable cpufreq for MediaTek arm64: defconfig: Enable MT6397 RTC Link: https://lore.kernel.org/r/9b90b407-025b-ec78-a626-faccdbc7ab39@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01Merge tag 'qcom-defconfig-for-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm defconfig updates for v5.18 The Qualcomm Snapdragon 8916 devices come in both 32- or 64-bit form, and even though the typical case so far has been to 64-bit, it's possible to run the Dragonboard 410c in either mode. Enable the relevant drivers in multi_v7_defconfig to enable this, and other Snapdragon 8916 devices to run the 32-bit kernel. * tag 'qcom-defconfig-for-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-03-01ARM: PXA: fix up decompressor codeArnd Bergmann
The earlier removal of two boards caused a build regression, fix it by removing the extraneous '||'. Reported-by: kernel test robot <lkp@intel.com> Fixes: 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit (git 2.34.1) at 2025-10-01 09:48:28 +0000