aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-06-05KVM: x86: Add a capability to configure bus frequency for APIC timerIsaku Yamahata1-0/+27
Add KVM_CAP_X86_APIC_BUS_CYCLES_NS capability to configure the APIC bus clock frequency for APIC timer emulation. Allow KVM_ENABLE_CAPABILITY(KVM_CAP_X86_APIC_BUS_CYCLES_NS) to set the frequency in nanoseconds. When using this capability, the user space VMM should configure CPUID leaf 0x15 to advertise the frequency. Vishal reported that the TDX guest kernel expects a 25MHz APIC bus frequency but ends up getting interrupts at a significantly higher rate. The TDX architecture hard-codes the core crystal clock frequency to 25MHz and mandates exposing it via CPUID leaf 0x15. The TDX architecture does not allow the VMM to override the value. In addition, per Intel SDM: "The APIC timer frequency will be the processor’s bus clock or core crystal clock frequency (when TSC/core crystal clock ratio is enumerated in CPUID leaf 0x15) divided by the value specified in the divide configuration register." The resulting 25MHz APIC bus frequency conflicts with the KVM hardcoded APIC bus frequency of 1GHz. The KVM doesn't enumerate CPUID leaf 0x15 to the guest unless the user space VMM sets it using KVM_SET_CPUID. If the CPUID leaf 0x15 is enumerated, the guest kernel uses it as the APIC bus frequency. If not, the guest kernel measures the frequency based on other known timers like the ACPI timer or the legacy PIT. As reported by Vishal the TDX guest kernel expects a 25MHz timer frequency but gets timer interrupt more frequently due to the 1GHz frequency used by KVM. To ensure that the guest doesn't have a conflicting view of the APIC bus frequency, allow the userspace to tell KVM to use the same frequency that TDX mandates instead of the default 1Ghz. Reported-by: Vishal Annapurve <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Isaku Yamahata <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> Co-developed-by: Reinette Chatre <[email protected]> Signed-off-by: Reinette Chatre <[email protected]> Reviewed-by: Xiaoyao Li <[email protected]> Reviewed-by: Yuan Yao <[email protected]> Link: https://lore.kernel.org/r/6748a4c12269e756f0c48680da8ccc5367c31ce7.1714081726.git.reinette.chatre@intel.com Signed-off-by: Sean Christopherson <[email protected]>
2024-06-05KVM: x86: Make nanoseconds per APIC bus cycle a VM variableIsaku Yamahata5-4/+9
Introduce the VM variable "nanoseconds per APIC bus cycle" in preparation to make the APIC bus frequency configurable. The TDX architecture hard-codes the core crystal clock frequency to 25MHz and mandates exposing it via CPUID leaf 0x15. The TDX architecture does not allow the VMM to override the value. In addition, per Intel SDM: "The APIC timer frequency will be the processor’s bus clock or core crystal clock frequency (when TSC/core crystal clock ratio is enumerated in CPUID leaf 0x15) divided by the value specified in the divide configuration register." The resulting 25MHz APIC bus frequency conflicts with the KVM hardcoded APIC bus frequency of 1GHz. Introduce the VM variable "nanoseconds per APIC bus cycle" to prepare for allowing userspace to tell KVM to use the frequency that TDX mandates instead of the default 1Ghz. Doing so ensures that the guest doesn't have a conflicting view of the APIC bus frequency. Signed-off-by: Isaku Yamahata <[email protected]> Reviewed-by: Maxim Levitsky <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> [reinette: rework changelog] Signed-off-by: Reinette Chatre <[email protected]> Reviewed-by: Xiaoyao Li <[email protected]> Link: https://lore.kernel.org/r/ae75ce37c6c38bb4efd10a0a41932984c40b24ac.1714081726.git.reinette.chatre@intel.com Signed-off-by: Sean Christopherson <[email protected]>
2024-06-05KVM: x86: hyper-v: Calculate APIC bus frequency for Hyper-VIsaku Yamahata2-2/+1
Remove APIC_BUS_FREQUENCY and calculate it based on nanoseconds per APIC bus cycle. APIC_BUS_FREQUENCY is used only for HV_X64_MSR_APIC_FREQUENCY. The MSR is not frequently read, calculate it every time. There are two constants related to the APIC bus frequency: APIC_BUS_FREQUENCY and APIC_BUS_CYCLE_NS. Only one value is required because one can be calculated from the other: APIC_BUS_CYCLES_NS = 1000 * 1000 * 1000 / APIC_BUS_FREQUENCY. Remove APIC_BUS_FREQUENCY and instead calculate it when needed. This prepares for support of configurable APIC bus frequency by requiring to change only a single variable. Suggested-by: Maxim Levitsky <[email protected]> Signed-off-by: Isaku Yamahata <[email protected]> Reviewed-by: Maxim Levitsky <[email protected]> Reviewed-by: Xiaoyao Li <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> [reinette: rework changelog] Signed-off-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/76a659d0898e87ebd73ee7c922f984a87a6ab370.1714081726.git.reinette.chatre@intel.com Signed-off-by: Sean Christopherson <[email protected]>
2024-06-05arm64/io: add constant-argument checkArnd Bergmann1-20/+16
In some configurations __const_iowrite32_copy() does not get inlined and gcc runs into the BUILD_BUG(): In file included from <command-line>: In function '__const_memcpy_toio_aligned32', inlined from '__const_iowrite32_copy' at arch/arm64/include/asm/io.h:203:3, inlined from '__const_iowrite32_copy' at arch/arm64/include/asm/io.h:199:20: include/linux/compiler_types.h:487:45: error: call to '__compiletime_assert_538' declared with attribute error: BUILD_BUG failed 487 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:468:25: note: in definition of macro '__compiletime_assert' 468 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:487:9: note: in expansion of macro '_compiletime_assert' 487 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG' 59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed") | ^~~~~~~~~~~~~~~~ arch/arm64/include/asm/io.h:193:17: note: in expansion of macro 'BUILD_BUG' 193 | BUILD_BUG(); | ^~~~~~~~~ Move the check for constant arguments into the inline function to ensure it is still constant if the compiler decides against inlining it, and mark them as __always_inline to override the logic that sometimes leads to the compiler not producing the simplified output. Note that either the __always_inline annotation or the check for a constant value are sufficient here, but combining the two looks cleaner as it also avoids the macro. With clang-8 and older, the macro was still needed, but all versions of gcc and clang can reliably perform constant folding here. Fixes: ead79118dae6 ("arm64/io: Provide a WC friendly __iowriteXX_copy()") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Mark Rutland <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-06-05KVM: SNP: Fix LBR Virtualization for SNP guestRavi Bangoria1-0/+8
SEV-ES and thus SNP guest mandates LBR Virtualization to be _always_ ON. Although commit b7e4be0a224f ("KVM: SEV-ES: Delegate LBR virtualization to the processor") did the correct change for SEV-ES guests, it missed the SNP. Fix it. Reported-by: Srikanth Aithal <[email protected]> Fixes: b7e4be0a224f ("KVM: SEV-ES: Delegate LBR virtualization to the processor") Signed-off-by: Ravi Bangoria <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2024-06-05KVM: x86/mmu: Don't save mmu_invalidate_seq after checking private attrTao Su1-3/+0
Drop the second snapshot of mmu_invalidate_seq in kvm_faultin_pfn(). Before checking the mismatch of private vs. shared, mmu_invalidate_seq is saved to fault->mmu_seq, which can be used to detect an invalidation related to the gfn occurred, i.e. KVM will not install a mapping in page table if fault->mmu_seq != mmu_invalidate_seq. Currently there is a second snapshot of mmu_invalidate_seq, which may not be same as the first snapshot in kvm_faultin_pfn(), i.e. the gfn attribute may be changed between the two snapshots, but the gfn may be mapped in page table without hindrance. Therefore, drop the second snapshot as it has no obvious benefits. Fixes: f6adeae81f35 ("KVM: x86/mmu: Handle no-slot faults at the beginning of kvm_faultin_pfn()") Signed-off-by: Tao Su <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2024-06-05Merge tag 'kvmarm-fixes-6.10-1' of ↵Paolo Bonzini21-73/+391
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.10, take #1 - Large set of FP/SVE fixes for pKVM, addressing the fallout from the per-CPU data rework and making sure that the host is not involved in the FP/SVE switching any more - Allow FEAT_BTI to be enabled with NV now that FEAT_PAUTH is copletely supported - Fix for the respective priorities of Failed PAC, Illegal Execution state and Instruction Abort exceptions - Fix the handling of AArch32 instruction traps failing their condition code, which was broken by the introduction of ESR_EL2.ISS2 - Allow vpcus running in AArch32 state to be restored in System mode - Fix AArch32 GPR restore that would lose the 64 bit state under some conditions
2024-06-05arm64: armv8_deprecated: Fix warning in isndep cpuhp starting processWei Li1-0/+3
The function run_all_insn_set_hw_mode() is registered as startup callback of 'CPUHP_AP_ARM64_ISNDEP_STARTING', it invokes set_hw_mode() methods of all emulated instructions. As the STARTING callbacks are not expected to fail, if one of the set_hw_mode() fails, e.g. due to el0 mixed-endian is not supported for 'setend', it will report a warning: ``` CPU[2] cannot support the emulation of setend CPU 2 UP state arm64/isndep:starting (136) failed (-22) CPU2: Booted secondary processor 0x0000000002 [0x414fd0c1] ``` To fix it, add a check for INSN_UNAVAILABLE status and skip the process. Signed-off-by: Wei Li <[email protected]> Tested-by: Huisong Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2024-06-05ARM: dts: stm32: osd32: move pwr_regulators to commonSean Nyekjaer3-10/+5
According to the OSD32MP1 Power System overview[1] pwr_regulators; vdd-supply and vdd_3v3_usbfs-supply are hard-wired internally in the SIP module to vdd and ldo4. [1]: https://octavosystems.com/app_notes/osd32mp1-power-system-overview/#connections Signed-off-by: Sean Nyekjaer <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05ARM: dts: stm32: osd32: move usb phy power to commonSean Nyekjaer3-16/+8
According to the OSD32MP1 Power System overview[1] usb phy power is hard-wired internally in the SIP module to ldo4. [1]: https://octavosystems.com/app_notes/osd32mp1-power-system-overview/#connections Signed-off-by: Sean Nyekjaer <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05ARM: dts: stm32: Add arm,no-tick-in-suspend to STM32MP15xx STGEN timerMarek Vasut1-0/+1
STM32MP15xx RM0436 Rev 6 section 46.3 System timer generator (STGEN) states " Arm recommends that the system counter is in an always-on power domain. This is not supported in the current implementation, therefore STGEN should be saved and restored before Standby mode entry, and restored at Standby exit by secure software. ... " Instead of piling up workarounds in the firmware which is difficult to update, add "arm,no-tick-in-suspend" DT property into the timer node to indicate the timer is stopped in suspend, and let the kernel fix the timer up. Fixes: 8471a20253eb ("ARM: dts: stm32: add stm32mp157c initial support") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05ARM: dts: stm32: add goodix touchscreen on stm32mp135f-dkYannick Fertre2-0/+36
Touchscreen reset needs to be configured via the pinctrl not the driver (a pull-down resistor has been soldered onto the reset line which forces the touchscreen to reset state). Interrupt line must have a pull-down resistor in order to freeze the i2c address at 0x5D. Signed-off-by: Yannick Fertre <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05ARM: dts: stm32: enable camera support on stm32mp135f-dk boardAlain Volmat1-0/+87
On STM32MP135F-DK board the camera support is made of the CSI based GC2145 sensor, connected to the ST-MIPID02 CSI to parallel bridge, connected to the DCMIPP parallel input. Signed-off-by: Alain Volmat <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05ARM: dts: stm32: add DCMIPP pinctrl on STM32MP13x SoC familyAlain Volmat1-0/+33
Adds DCMIPP pinctrl support and assigns dedicated GPIO pins. Signed-off-by: Alain Volmat <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: add power domain on stm32mp25Patrick Delaunay2-0/+25
Add power domains on STM32MP25x SoC for supported low power modes: - CPU_PD0/1: domain for idle of each core Cortex A35 (CStop) - CLUSTER_PD: D1 domain with Stop1 and LP-Stop1 modes support when the Cortex A35 cluster and each device assigned to CPU1=CA35 are deactivated - RET_PD: D1 domain retention (VDDCore is reduced) to support the LPLV-Stop1 mode Signed-off-by: Patrick Delaunay <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: add usart6 on stm32mp257f-ev1 boardValentin Caron1-0/+10
Add node for USART6 on stm32mp257f-ev1 board. Signed-off-by: Valentin Caron <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: add usart6 pinctrl used on stm32mp257f-ev1 boardValentin Caron1-0/+41
Add pins for USART6 on GPIO connector on stm32mp257f-ev1 board. Signed-off-by: Valentin Caron <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: add usart nodes on stm32mp25Valentin Caron1-0/+72
Update device-tree stm32mp251.dtsi to add some USART features. Add u(s)art 1, 3, 4, 5, 6, 7, 8, 9 nodes and compatible, interrupts, clocks, access-controllers properties. Signed-off-by: Valentin Caron <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: enable STM32 access controller for RCCGabriel Fernandez1-0/+1
Use an STM32 access controller to filter the registration of clocks. Signed-off-by: Gabriel Fernandez <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-05arm64: dts: st: OP-TEE async notif on PPI 15 for stm32mp25Etienne Carriere2-1/+7
Define GIC PPI 15 (aka GIC interrupt line 31) for OP-TEE asynchronous notification. Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Pascal Paillet <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]>
2024-06-04arm64: dts: qcom: msm8994: Use mboxes properties for APCSLuca Weiss1-3/+3
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04arm64: dts: qcom: msm8976: Use mboxes properties for APCSLuca Weiss1-4/+4
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04arm64: dts: qcom: msm8953: Use mboxes properties for APCSLuca Weiss1-5/+5
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04arm64: dts: qcom: msm8939: Use mboxes properties for APCSLuca Weiss1-2/+2
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04arm64: dts: qcom: msm8916: Use mboxes properties for APCSLuca Weiss1-5/+5
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04ARM: dts: qcom: msm8974: Use mboxes properties for APCSLuca Weiss1-7/+7
Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04arm64: dts: microchip: sparx5_pcb135: move non-MMIO nodes out of axiKrzysztof Kozlowski1-48/+47
simple-bus nodes, so the "axi" node, should not have non-MMIO children as pointed out by simple-bus schema dtbs_check: sparx5_pcb135_emmc.dtb: axi@600000000: sfp-eth60: {'compatible': ... should not be valid under {'type': 'object'} from schema $id: http://devicetree.org/schemas/simple-bus.yaml# Reported-by: Rob Herring <[email protected]> Closes: https://lore.kernel.org/all/CAL_Jsq+PtL3HTKkA_gwTjb_i1mFZ+wW+qwin34HMYmwW7oNDFw@mail.gmail.com/ Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-04arm64: dts: microchip: sparx5_pcb134: move non-MMIO nodes out of axiKrzysztof Kozlowski1-178/+194
simple-bus nodes, so the "axi" node, should not have non-MMIO children as pointed out by simple-bus schema dtbs_check: sparx5_pcb134.dtb: axi@600000000: i2c-mux-0: {'compatible': ... should not be valid under {'type': 'object'} from schema $id: http://devicetree.org/schemas/simple-bus.yaml# Reported-by: Rob Herring <[email protected]> Closes: https://lore.kernel.org/all/CAL_Jsq+PtL3HTKkA_gwTjb_i1mFZ+wW+qwin34HMYmwW7oNDFw@mail.gmail.com/ Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Conor Dooley <[email protected]>
2024-06-04arm64: dts: qcom: sa8775p: Correct IRQ number of EL2 non-secure physical timerCong Zhang1-1/+1
The INTID of EL2 non-secure physical timer is 26. In linux, the IRQ number has a fixed 16 offset for PPIs. Therefore, the linux IRQ number of EL2 non-secure physical timer should be 10 (26 - 16). Fixes: 603f96d4c9d0 ("arm64: dts: qcom: add initial support for qcom sa8775p-ride") Signed-off-by: Cong Zhang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
2024-06-04KVM: arm64: Ensure that SME controls are disabled in protected modeFuad Tabba2-0/+18
KVM (and pKVM) do not support SME guests. Therefore KVM ensures that the host's SME state is flushed and that SME controls for enabling access to ZA storage and for streaming are disabled. pKVM needs to protect against a buggy/malicious host. Ensure that it wouldn't run a guest when protected mode is enabled should any of the SME controls be enabled. Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Refactor CPACR trap bit setting/clearing to use ELx formatFuad Tabba6-19/+14
When setting/clearing CPACR bits for EL0 and EL1, use the ELx format of the bits, which covers both. This makes the code clearer, and reduces the chances of accidentally missing a bit. No functional change intended. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Consolidate initializing the host data's fpsimd_state/sve in pKVMFuad Tabba5-21/+22
Now that we have introduced finalize_init_hyp_mode(), lets consolidate the initializing of the host_data fpsimd_state and sve state. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Eagerly restore host fpsimd/sve state in pKVMFuad Tabba4-5/+93
When running in protected mode we don't want to leak protected guest state to the host, including whether a guest has used fpsimd/sve. Therefore, eagerly restore the host state on guest exit when running in protected mode, which happens only if the guest has used fpsimd/sve. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Allocate memory mapped at hyp for host sve state in pKVMFuad Tabba7-0/+124
Protected mode needs to maintain (save/restore) the host's sve state, rather than relying on the host kernel to do that. This is to avoid leaking information to the host about guests and the type of operations they are performing. As a first step towards that, allocate memory mapped at hyp, per cpu, for the host sve state. The following patch will use this memory to save/restore the host state. Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Specialize handling of host fpsimd state on trapFuad Tabba3-1/+13
In subsequent patches, n/vhe will diverge on saving the host fpsimd/sve state when taking a guest fpsimd/sve trap. Add a specialized helper to handle it. No functional change intended. Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Abstract set/clear of CPTR_EL2 bits behind helperFuad Tabba4-19/+73
The same traps controlled by CPTR_EL2 or CPACR_EL1 need to be toggled in different parts of the code, but the exact bits and their polarity differ between these two formats and the mode (vhe/nvhe/hvhe). To reduce the amount of duplicated code and the chance of getting the wrong bit/polarity or missing a field, abstract the set/clear of CPTR_EL2 bits behind a helper. Since (h)VHE is the way of the future, use the CPACR_EL1 format, which is a subset of the VHE CPTR_EL2, as a reference. No functional change intended. Suggested-by: Oliver Upton <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Fix prototype for __sve_save_state/__sve_restore_stateFuad Tabba2-3/+4
Since the prototypes for __sve_save_state/__sve_restore_state at hyp were added, the underlying macro has acquired a third parameter for saving/restoring ffr. Fix the prototypes to account for the third parameter, and restore the ffr for the guest since it is saved. Suggested-by: Mark Brown <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04KVM: arm64: Reintroduce __sve_save_stateFuad Tabba2-0/+7
Now that the hypervisor is handling the host sve state in protected mode, it needs to be able to save it. This reverts commit e66425fc9ba3 ("KVM: arm64: Remove unused __sve_save_state"). Reviewed-by: Oliver Upton <[email protected]> Signed-off-by: Fuad Tabba <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]>
2024-06-04arm64: zynqmp: Add coresight cpu debug supportSean Anderson2-0/+44
Add coresight debug support to the device tree. This can be useful when panicking, especially when a core is hung in EL3. Signed-off-by: Sean Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-04powerpc/crypto: Add generated P8 asm to .gitignoreNathan Lynch1-0/+2
Looks like drivers/crypto/vmx/.gitignore should have been merged into arch/powerpc/crypto/.gitignore as part of commit 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") so that all generated asm files are ignored. Signed-off-by: Nathan Lynch <[email protected]> Fixes: 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/20240603-powerpc-crypto-ignore-p8-asm-v1-1-05843fec2bb7@linux.ibm.com
2024-06-04powerpc/mm/drmem: Silence drmem_init() early returnNathan Lynch1-3/+1
It's not an error or noteworthy condition if the "ibm,dynamic-reconfiguration-memory" node isn't present. Drop the needless message. Signed-off-by: Nathan Lynch <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-06-04powerpc/pseries/vas: Use usleep_range() to support HCALL delayHaren Myneni1-1/+21
VAS allocate, modify and deallocate HCALLs returns H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy delay and expects OS to reissue HCALL after that delay. But using msleep() will often sleep at least 20 msecs even though the hypervisor suggests OS reissue these HCALLs after 1 or 10msecs. The open and close VAS window functions hold mutex and then issue these HCALLs. So these operations can take longer than the necessary when multiple threads issue open or close window APIs simultaneously, especially might affect the performance in the case of repeat open/close APIs for each compression request. Multiple tasks can open / close VAS windows at the same time which depends on the available VAS credits. For example, 240 cores system provides 4800 VAS credits. It means 4800 tasks can execute open VAS windows HCALLs with the mutex. Since each msleep() will often sleep more than 20 msecs, some tasks are waiting more than 120 secs to acquire mutex. It can cause hung traces for these tasks in dmesg due to mutex contention around open/close HCALLs. Instead of msleep(), use usleep_range() to ensure sleep with the expected value before issuing HCALL again. So since each task sleep 10 msecs maximum, this patch allow more tasks can issue open/close VAS calls without any hung traces in the dmesg. Signed-off-by: Haren Myneni <[email protected]> Suggested-by: Nathan Lynch <[email protected]> Reviewed-by: Nathan Lynch <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-06-04powerpc/numa: Online a node if PHB is attached.Nilay Shroff2-1/+27
In the current design, a numa-node is made online only if that node is attached to cpu/memory. With this design, if any PCI/IO device is found to be attached to a numa-node which is not online then the numa-node id of the corresponding PCI/IO device is set to NUMA_NO_NODE(-1). This design may negatively impact the performance of PCIe device if the numa-node assigned to PCIe device is -1 because in such case we may not be able to accurately calculate the distance between two nodes. The multi-controller NVMe PCIe disk has an issue with calculating the node distance if the PCIe NVMe controller is attached to a PCI host bridge which has numa-node id value set to NUMA_NO_NODE. This patch helps fix this ensuring that a cpu/memory less numa node is made online if it's attached to PCI host bridge. Signed-off-by: Nilay Shroff <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-06-04powerpc/pseries/iommu: Split Dynamic DMA Window to be used in Hybrid modeGaurav Batra2-17/+54
Dynamic DMA Window (DDW) supports TCEs that are backed by 2MB page size. In most configurations, DDW is big enough to pre-map all of LPAR memory for IO. Pre-mapping of memory for DMA results in improvements in IO performance. Persistent memory, vPMEM, can be assigned to an LPAR as well. vPMEM is not contiguous with LPAR memory and usually is assigned at high memory addresses. This makes is not possible to pre-map both vPMEM and LPAR memory in the same DDW. For a dedicated adapter this limitation is not an issue. Dedicated adapters can have both Default DMA window, which is backed by 4K page size and a DDW backed by 2MB page size TCEs. In this scenario, LPAR memory is pre-mapped in the DDW. Any DMA going to the vPMEM is routed via dynamically allocated TCEs in the default window. The issue arises with SR-IOV adapters. There is only one DMA window - either Default or DDW. If an LPAR has vPMEM assigned, memory is not pre-mapped in the DDW since TCEs needs to be allocated for vPMEM as well. In this case, DDW is created and TCEs are dynamically allocated for both vPMEM and LPAR memory. Today, DDW is only used in single mode - direct mapped TCEs or dynamically mapped TCEs. This enhancement breaks a single DDW in 2 regions - 1. First region to pre-map LPAR memory 2. Second region to dynamically allocate TCEs for IO to vPMEM The DDW is split only if it is big enough to pre-map complete LPAR memory and still have some space left to dynamically map vPMEM. Maximum size possible DDW is created as permitted by the Hypervisor. Signed-off-by: Gaurav Batra <[email protected]> Reviewed-by: Brian King <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-06-04m68k: amiga: Turn off Warp1260 interrupts during bootPaolo Pisati1-0/+9
On an Amiga 1200 equipped with a Warp1260 accelerator, an interrupt storm coming from the accelerator board causes the machine to crash in local_irq_enable() or auto_irq_enable(). Disabling interrupts for the Warp1260 in amiga_parse_bootinfo() fixes the problem. Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Paolo Pisati <[email protected]> Reviewed-by: Michael Schmitz <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-03KVM: SVM: Consider NUMA affinity when allocating per-CPU save_areaLi RongQing3-9/+9
save_area of per-CPU svm_data are dominantly accessed from their own local CPUs, so allocate them node-local for performance reason so rename __snp_safe_alloc_page as snp_safe_alloc_page_node which accepts numa node id as input parameter, svm_cpu_init call it with node id switched from cpu id Signed-off-by: Li RongQing <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
2024-06-03KVM: SVM: not account memory allocation for per-CPU svm_dataLi RongQing3-6/+17
The allocation for the per-CPU save area in svm_cpu_init shouldn't be accounted, So introduce __snp_safe_alloc_page helper, which has gfp flag as input, svm_cpu_init calls __snp_safe_alloc_page with GFP_KERNEL, snp_safe_alloc_page calls __snp_safe_alloc_page with GFP_KERNEL_ACCOUNT as input Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Li RongQing <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
2024-06-03KVM: SVM: remove useless input parameter in snp_safe_alloc_pageLi RongQing4-8/+9
The input parameter 'vcpu' in snp_safe_alloc_page is not used. Therefore, remove it. Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Li RongQing <[email protected]> Reviewed-by: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
2024-06-03KVM: x86/pmu: Manipulate FIXED_CTR_CTRL MSR with macrosDapeng Mi3-11/+17
Magic numbers are used to manipulate the bit fields of FIXED_CTR_CTRL MSR. This makes reading code become difficult, so use pre-defined macros to replace these magic numbers. Signed-off-by: Dapeng Mi <[email protected]> Link: https://lore.kernel.org/r/[email protected] [sean: drop unnecessary curly braces] Signed-off-by: Sean Christopherson <[email protected]>
2024-06-03KVM: x86/pmu: Change ambiguous _mask suffix to _rsvd in kvm_pmuDapeng Mi5-29/+29
Several '_mask' suffixed variables such as, global_ctrl_mask, are defined in kvm_pmu structure. However the _mask suffix is ambiguous and misleading since it's not a real mask with positive logic. On the contrary it represents the reserved bits of corresponding MSRs and these bits should not be accessed. Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Dapeng Mi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>