aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-08-06KVM: s390: fix validity interception issue when gisa is switched offMichael Mueller1-1/+6
We might run into a SIE validity if gisa has been disabled either via using kernel parameter "kvm.use_gisa=0" or by setting the related sysfs attribute to N (echo N >/sys/module/kvm/parameters/use_gisa). The validity is caused by an invalid value in the SIE control block's gisa designation. That happens because we pass the uninitialized gisa origin to virt_to_phys() before writing it to the gisa designation. To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0. kvm_s390_get_gisa_desc() is used to determine which gisa designation to set in the SIE control block. A value of 0 in the gisa designation disables gisa usage. The issue surfaces in the host kernel with the following kernel message as soon a new kvm guest start is attemted. kvm: unhandled validity intercept 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0 Cc: [email protected] Reported-by: Christian Borntraeger <[email protected]> Fixes: fe0ef0030463 ("KVM: s390: sort out physical vs virtual pointers usage") Signed-off-by: Michael Mueller <[email protected]> Tested-by: Christian Borntraeger <[email protected]> Reviewed-by: Janosch Frank <[email protected]> Link: https://lore.kernel.org/r/[email protected] Message-ID: <[email protected]> Signed-off-by: Janosch Frank <[email protected]>
2024-08-06Revert "crypto: arm64/poly1305 - move data to rodata section"Herbert Xu1-3/+0
This reverts commit 47d96252099a7184b4bad852fcfa3c233c1d2f71. It causes build issues as detected by the kernel test robot. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Herbert Xu <[email protected]>
2024-08-05arm64: dts: ti: k3-j722s: Fix gpio-range for main_pmx0Jared McArthur1-1/+2
Commit 5e5c50964e2e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed a hole within gpio-range for main_pmx0. As a result, automatic mapping of GPIO to pin control for gpios within the main_pmx0 domain is broken. Fix this by correcting the gpio-range. Fixes: 5e5c50964e2e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties") Signed-off-by: Jared McArthur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-08-05arm64: dts: ti: k3-am62p: Fix gpio-range for main_pmx0Jared McArthur1-1/+2
Commit d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed a hole within gpio-range for main_pmx0. As a result, automatic mapping of GPIO to pin control for gpios within the main_pmx0 domain is broken. Fix this by correcting the gpio-range. Fixes: d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") Signed-off-by: Jared McArthur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-08-05arm64: dts: ti: k3-am62p: Add gpio-ranges for mcu_gpio0Jared McArthur1-0/+2
Commit d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") introduced pinmux range definition for gpio-ranges, however missed introducing the range description for the mcu_gpio node. As a result, automatic mapping of GPIO to pin control for mcu gpios is broken. Fix this by introducing the proper ranges. Fixes: d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") Signed-off-by: Jared McArthur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-08-05Merge patch series "RISC-V: Parse DT for Zkr to seed KASLR"Palmer Dabbelt9-16/+224
Jesse Taube <[email protected]> says: Add functions to pi/fdt_early.c to help parse the FDT to check if the isa string has the Zkr extension. Then use the Zkr extension to seed the KASLR base address. The first two patches fix the visibility of symbols. * b4-shazam-merge: RISC-V: Use Zkr to seed KASLR base address RISC-V: pi: Add kernel/pi/pi.h RISC-V: lib: Add pi aliases for string functions RISC-V: pi: Force hidden visibility for all symbol references Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-08-05RISC-V: Use Zkr to seed KASLR base addressJesse Taube5-2/+199
Parse the device tree for Zkr in the isa string. If Zkr is present, use it to seed the kernel base address. On an ACPI system, as of this commit, there is no easy way to check if Zkr is present. Blindly running the instruction isn't an option as; we have to be able to trust the firmware. Signed-off-by: Jesse Taube <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Tested-by: Zong Li <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-08-05RISC-V: pi: Add kernel/pi/pi.hJesse Taube3-14/+20
Add pi.h header for declarations of the kernel/pi prefixed functions and any other related declarations. Suggested-by: Charlie Jenkins <[email protected]> Signed-off-by: Jesse Taube <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-08-05RISC-V: lib: Add pi aliases for string functionsJesse Taube3-0/+4
memset, strcmp, and strncmp are all used in the __pi_ section, add SYM_FUNC_ALIAS for them. When KASAN is enabled in <asm/string.h> __pi___memset is also needed. Suggested-by: Charlie Jenkins <[email protected]> Signed-off-by: Jesse Taube <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-08-05RISC-V: pi: Force hidden visibility for all symbol referencesJesse Taube1-0/+1
Eliminate all GOT entries in the .pi section, by forcing hidden visibility for all symbol references, which informs the compiler that such references will be resolved at link time without the need for allocating GOT entries. Include linux/hidden.h in Makefile, like arm64, for the hidden visibility attribute. Signed-off-by: Jesse Taube <[email protected]> Reviewed-by: Alexandre Ghiti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-08-05ARM: dts: omap3-n900: correct the accelerometer orientationSicelo A. Mhlongo1-1/+1
Negate the values reported for the accelerometer z-axis in order to match Documentation/devicetree/bindings/iio/mount-matrix.txt. Fixes: 14a213dcb004 ("ARM: dts: n900: use iio driver for accelerometer") Signed-off-by: Sicelo A. Mhlongo <[email protected]> Reviewed-By: Andreas Kemnade <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]>
2024-08-05arm64: dts: rockchip: Simplify network PHY connection on qnap-ts433Uwe Kleine-König1-3/+1
While it requires to have the right phy driver loaded (i.e. motorcomm) to make the phy asserting the right delays, this is generally the preferred way to define the MAC <-> PHY connection. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-08-05perf/x86/intel/bts: Fix comment about default perf_event_paranoid settingJames Clark1-3/+0
The default paranoid setting was updated in commit 0161028b7c8a ("perf/core: Change the default paranoia level to 2") so this comment is no longer true. Signed-off-by: James Clark <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Use D0:F0 as a default deviceZhenyu Wang1-0/+4
Some uncore PMON registers are located in the MMIO space of the Host Bridge and DRAM Controller device, which is located at D0:F0 for Tiger Lake and later client generation. Use D0:F0 as a default device. So it doesn't need to keep adding the complete Device ID list for each generation anymore. Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add LNL uncore iMC freerunning supportZhenyu Wang1-0/+1
LNL uncore imc freerunning counters keep same as previous HW. Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add Lunar Lake supportKan Liang3-0/+141
The uncore subsystem for Lunar Lake is similar to the previous Meteor Lake. The uncore PerfMon registers are located at both MSR and MMIO space. The ARB and iMC are kept. There is no difference from the Meteor Lake. Move the global control initialization to the first box of the CBOX. The sNCU is moved to the MMIO space. The HBO is newly added and only be accessed from the MMIO space. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Factor out common MMIO init and ops functionsKan Liang1-17/+30
Some uncore PMON registers are located in the MMIO space. For the client machine, the MMIO space is usually located at D0:F0 but in a different BAR. For example, some uncore PMON registers are located in the SAF BAR, not the MCHBAR in the Lunar Lake. The current __uncore_imc_init_box() hard code the BAR information. Factor out the uncore_get_box_mmio_addr() which uses the BAR information as a parameter. The only change is the error output message. The hardcode name 'MCHBAR' is replaced by the offset of a BAR. Add a new macro, MMIO_UNCORE_COMMON_OPS(), since the MMIO ops functions are usually the same among different generations. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add Arrow Lake supportKan Liang1-0/+3
>From the perspective of the uncore PMU, the Arrow Lake is the same as the previous Meteor Lake. The only difference is the event list, which will be supported in the perf tool later. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05x86/mm/ident_map: Use gbpages only where full GB page should be mapped.Steve Wahl1-5/+18
When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. Signed-off-by: Steve Wahl <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Pavin Joseph <[email protected]> Tested-by: Sarah Brofeldt <[email protected]> Tested-by: Eric Hagberg <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-05x86/kexec: Add EFI config table identity mapping for kexec kernelTao Liu1-0/+27
A kexec kernel boot failure is sometimes observed on AMD CPUs due to an unmapped EFI config table array. This can be seen when "nogbpages" is on the kernel command line, and has been observed as a full BIOS reboot rather than a successful kexec. This was also the cause of reported regressions attributed to Commit 7143c5f4cf20 ("x86/mm/ident_map: Use gbpages only where full GB page should be mapped.") which was subsequently reverted. To avoid this page fault, explicitly include the EFI config table array in the kexec identity map. Further explanation: The following 2 commits caused the EFI config table array to be accessed when enabling sev at kernel startup. commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features earlier during boot") commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature detection/setup") This is in the code that examines whether SEV should be enabled or not, so it can even affect systems that are not SEV capable. This may result in a page fault if the EFI config table array's address is unmapped. Since the page fault occurs before the new kernel establishes its own identity map and page fault routines, it is unrecoverable and kexec fails. Most often, this problem is not seen because the EFI config table array gets included in the map by the luck of being placed at a memory address close enough to other memory areas that *are* included in the map created by kexec. Both the "nogbpages" command line option and the "use gpbages only where full GB page should be mapped" change greatly reduce the chance of being included in the map by luck, which is why the problem appears. Signed-off-by: Tao Liu <[email protected]> Signed-off-by: Steve Wahl <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Pavin Joseph <[email protected]> Tested-by: Sarah Brofeldt <[email protected]> Tested-by: Eric Hagberg <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-05arm64: dts: ti: k3-am62-verdin-dahlia: Keep CTRL_SLEEP_MOCI# regulator onFrancesco Dolcini2-28/+0
This reverts commit 3935fbc87ddebea5439f3ab6a78b1e83e976bf88. CTRL_SLEEP_MOCI# is a signal that is defined for all the SoM implementing the Verdin family specification, this signal is supposed to control the power enable in the carrier board when the system is in deep sleep mode. However this is not possible with Texas Instruments AM62 SoC, IOs output buffer is disabled in deep sleep and IOs are in tri-state mode. Given that we cannot properly control this pin, force it to be always high to minimize potential issues. Fixes: 3935fbc87dde ("arm64: dts: ti: k3-am62-verdin-dahlia: support sleep-moci") Cc: <[email protected]> Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1361669/am625-gpio-output-state-in-deep-sleep/5244802 Signed-off-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-08-05arm64: dts: layerscape: fix thermal node names lengthKrzysztof Kozlowski6-9/+9
Linux kernel expects thermal zone node names to be maximum of 19 characters (see THERMAL_NAME_LENGTH, including terminating NUL byte) and bindings/dtbs_check points that: fsl-ls2088a-rdb.dtb: thermal-zones: 'core-cluster1-thermal', 'core-cluster2-thermal', 'core-cluster3-thermal', 'core-cluster4-thermal' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$', 'pinctrl-[0-9]+' Name longer than 19 characters leads to driver probe errors when registering such thermal zone. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx8mm-venice-gw72xx-0x: Remove compatible from dtsoFabio Estevam3-12/+0
There is no need to describe the compatible string inside a dtso file. dt-schema produces super verbose warnings about that. Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Parthiban Nallathambi <[email protected]> Acked-by: Tim Harvey <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx8mm-phygate-tauri-l: Remove compatible from dtsoFabio Estevam3-16/+0
There is no need to describe the compatible string inside a dtso file. dt-schema produces super verbose warnings about that. Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Parthiban Nallathambi <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95-19x19-evk: add pwm fan controlFrank Li1-0/+61
Add pwm fan and overwrite default thermal nodes. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95: add thermal_zone labelFrank Li1-1/+1
Add thermal_zone label because it may be overwrite by board level dts file. Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95-19x19-evk: add flexspi and child nodeFrank Li1-0/+41
Add flexspi and child flash node. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95: add flexspi nodeFrank Li1-0/+16
Add flexspi support. Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95-19x19-evk: Add audio related nodesFrank Li1-0/+238
Add sai1, sai2. Add i2c4 and wm8962 and other dependent nodes. Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95: add sai[1..6], xcvr and micfillFrank Li1-0/+111
Add sai[1..6], NXP Audio Transceiver (XCVR) Controller and MICFIL Digital Audio Interface (MICFIL). Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx95: add edma[1..3] nodesFrank Li1-0/+235
Add eDMA1, eDMA2 and eDMA3 support for iMX95. Add dmas and dma-names for each peripheral, which use eDMA. Signed-off-by: Frank Li <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05ARM: mach-imx: imx6sx: Remove Ethernet refclock settingFabio Estevam1-22/+0
The Ethernet refclock configuration is board specific and should not be harcoded in machine code. Remove it to align with the imx6ul commit e87f3be1c7f8 ("ARM: mach-imx: imx6ul: remove not optional ethernet refclock overwrite"). Clearing bits 13 and 17 of GPR1 is the POR values, so this change does not affect existing boards in mainline. Tested on imx6sx-udoo-neo and imx6sx-sdb boards. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05ARM: dts: imx6sx-udoo-neo: Properly configure ENET_REFFabio Estevam1-0/+5
By default, the ENET_REF is configured at 125MHz on i.MX6SX, which works well for boards that operate in RGMII mode. The imx6sx-udoo-neo has a KSZ8091 Ethernet PHY that is connected via RMII interface, so a 50MHz ENET_REF clock is expected. Describe the IMX6SX_CLK_ENET_REF accordingly. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05arm64: dts: imx93: support i.MX93-14x14-EVK boardPeng Fan2-0/+469
Add the board device tree with sdhc1/2, cm33, flexcan, mu, lpuart1, lpi2c1/2, usb enabled and etc, which to support the i.MX 93 14x14 Evaluation kit that is an automotive market oriented evaluation board with i.MX 93 application processors in a 14x14mm package. Signed-off-by: Ye Li <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-05KVM: PPC: Book3S HV: Refactor HFSCR emulation for KVM guestsGautam Menghani1-4/+12
Refactor HFSCR emulation for KVM guests when they exit out with H_FAC_UNAVAIL to use a switch case instead of checking all "cause" values, since the "cause" values are mutually exclusive; and this is better expressed with a switch case. Signed-off-by: Gautam Menghani <[email protected]> Reviewed-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2024-08-04Merge tag 'x86-urgent-2024-08-04' of ↵Linus Torvalds8-17/+36
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: - Prevent a deadlock on cpu_hotplug_lock in the aperf/mperf driver. A recent change in the ACPI code which consolidated code pathes moved the invocation of init_freq_invariance_cppc() to be moved to a CPU hotplug handler. The first invocation on AMD CPUs ends up enabling a static branch which dead locks because the static branch enable tries to acquire cpu_hotplug_lock but that lock is already held write by the hotplug machinery. Use static_branch_enable_cpuslocked() instead and take the hotplug lock read for the Intel code path which is invoked from the architecture code outside of the CPU hotplug operations. - Fix the number of reserved bits in the sev_config structure bit field so that the bitfield does not exceed 64 bit. - Add missing Zen5 model numbers - Fix the alignment assumptions of pti_clone_pgtable() and clone_entry_text() on 32-bit: The code assumes PMD aligned code sections, but on 32-bit the kernel entry text is not PMD aligned. So depending on the code size and location, which is configuration and compiler dependent, entry text can cross a PMD boundary. As the start is not PMD aligned adding PMD size to the start address is larger than the end address which results in partially mapped entry code for user space. That causes endless recursion on the first entry from userspace (usually #PF). Cure this by aligning the start address in the addition so it ends up at the next PMD start address. clone_entry_text() enforces PMD mapping, but on 32-bit the tail might eventually be PTE mapped, which causes a map fail because the PMD for the tail is not a large page mapping. Use PTI_LEVEL_KERNEL_IMAGE for the clone() invocation which resolves to PTE on 32-bit and PMD on 64-bit. - Zero the 8-byte case for get_user() on range check failure on 32-bit The recend consolidation of the 8-byte get_user() case broke the zeroing in the failure case again. Establish it by clearing ECX before the range check and not afterwards as that obvioulsy can't be reached when the range check fails * tag 'x86-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/uaccess: Zero the 8-byte get_range case on failure on 32-bit x86/mm: Fix pti_clone_entry_text() for i386 x86/mm: Fix pti_clone_pgtable() alignment assumption x86/setup: Parse the builtin command line before merging x86/CPU/AMD: Add models 0x60-0x6f to the Zen5 range x86/sev: Fix __reserved field in sev_config x86/aperfmperf: Fix deadlock on cpu_hotplug_lock
2024-08-04Merge tag 'perf-urgent-2024-08-04' of ↵Linus Torvalds2-12/+15
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 perf fixes from Thomas Gleixner: - Move the smp_processor_id() invocation back into the non-preemtible region, so that the result is valid to use - Add the missing package C2 residency counters for Sierra Forest CPUs to make the newly added support actually useful * tag 'perf-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Fix smp_processor_id()-in-preemptible warnings perf/x86/intel/cstate: Add pkg C2 residency counter for Sierra Forest
2024-08-04arm: dts: arm: versatile-ab: Fix duplicate clock node nameRob Herring (Arm)1-1/+1
Commit 04f08ef291d4 ("arm/arm64: dts: arm: Use generic clock and regulator nodenames") renamed nodes and created 2 "clock-24000000" nodes (at different paths). The kernel can't handle these duplicate names even though they are at different paths. Fix this by renaming one of the nodes to "clock-pclk". This name is aligned with other Arm boards (those didn't have a known frequency to use in the node name). Fixes: 04f08ef291d4 ("arm/arm64: dts: arm: Use generic clock and regulator nodenames") Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Rob Herring (Arm) <[email protected]> Tested-by: Guenter Roeck <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Tested-by: Linus Walleij <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2024-08-04arm64: dts: imx93: drop duplicated propertiesPeng Fan2-6/+0
'#address-cells' and '#size-cells' are already included in soc device tree, no need add them in board device tree. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-04arm64: dts: imx95: add p2a reply channelPeng Fan1-1/+1
For Platform to Agent(p2a) notification, i.MX95 System Manager(SM) firmware requires a reply communication. So add mailbox channel for p2a reply communication. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-03Merge tag 'parisc-for-6.11-rc2' of ↵Linus Torvalds3-2/+12
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: - fix unaligned memory accesses when calling BPF functions - adjust memory size constants to fix possible DMA corruptions * tag 'parisc-for-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: fix a possible DMA corruption parisc: fix unaligned accesses in BPF
2024-08-02x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequencyMichael Kelley1-0/+1
A Linux guest on Hyper-V gets the TSC frequency from a synthetic MSR, if available. In this case, set X86_FEATURE_TSC_KNOWN_FREQ so that Linux doesn't unnecessarily do refined TSC calibration when setting up the TSC clocksource. With this change, a message such as this is no longer output during boot when the TSC is used as the clocksource: [ 1.115141] tsc: Refined TSC clocksource calibration: 2918.408 MHz Furthermore, the guest and host will have exactly the same view of the TSC frequency, which is important for features such as the TSC deadline timer that are emulated by the Hyper-V host. Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Roman Kisel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
2024-08-02Merge tag 'arm64-fixes' of ↵Linus Torvalds5-9/+40
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Expand the speculative SSBS errata workaround to more CPUs - Ensure jump label changes are visible to all CPUs with a kick_all_cpus_sync() (and also enable jump label batching as part of the fix) - The shadow call stack sanitiser is currently incompatible with Rust, make CONFIG_RUST conditional on !CONFIG_SHADOW_CALL_STACK * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: jump_label: Ensure patched jump_labels are visible to all CPUs rust: SHADOW_CALL_STACK is incompatible with Rust arm64: errata: Expand speculative SSBS workaround (again) arm64: cputype: Add Cortex-A725 definitions arm64: cputype: Add Cortex-X1C definitions
2024-08-02KVM: arm64: vgic: fix unexpected unlock sparse warningsSebastian Ott2-2/+2
Get rid of unexpected unlock sparse warnings in vgic code by adding an annotation to vgic_queue_irq_unlock(). arch/arm64/kvm/vgic/vgic.c:334:17: warning: context imbalance in 'vgic_queue_irq_unlock' - unexpected unlock arch/arm64/kvm/vgic/vgic.c:419:5: warning: context imbalance in 'kvm_vgic_inject_irq' - different lock contexts for basic block Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-08-02KVM: arm64: fix kdoc warnings in W=1 buildsSebastian Ott4-11/+17
Fix kdoc warnings by adding missing function parameter descriptions or by conversion to a normal comment. Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-08-02KVM: arm64: fix override-init warnings in W=1 buildsSebastian Ott3-0/+7
Add -Wno-override-init to the build flags for sys_regs.c, handle_exit.c, and switch.c to fix warnings like the following: arch/arm64/kvm/hyp/vhe/switch.c:271:43: warning: initialized field overwritten [-Woverride-init] 271 | [ESR_ELx_EC_CP15_32] = kvm_hyp_handle_cp15_32, | Signed-off-by: Sebastian Ott <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-08-02KVM: arm64: free kvm->arch.nested_mmus with kvfree()Danilo Krummrich1-1/+1
kvm->arch.nested_mmus is allocated with kvrealloc(), hence free it with kvfree() instead of kfree(). Fixes: 4f128f8e1aaa ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") Signed-off-by: Danilo Krummrich <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-08-02Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds7-20/+24
Pull kvm updates from Paolo Bonzini: "The bulk of the changes here is a largish change to guest_memfd, delaying the clearing and encryption of guest-private pages until they are actually added to guest page tables. This started as "let's make it impossible to misuse the API" for SEV-SNP; but then it ballooned a bit. The new logic is generally simpler and more ready for hugepage support in guest_memfd. Summary: - fix latent bug in how usage of large pages is determined for confidential VMs - fix "underline too short" in docs - eliminate log spam from limited APIC timer periods - disallow pre-faulting of memory before SEV-SNP VMs are initialized - delay clearing and encrypting private memory until it is added to guest page tables - this change also enables another small cleanup: the checks in SNP_LAUNCH_UPDATE that limit it to non-populated, private pages can now be moved in the common kvm_gmem_populate() function - fix compilation error that the RISC-V merge introduced in selftests" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/mmu: fix determination of max NPT mapping level for private pages KVM: riscv: selftests: Fix compile error KVM: guest_memfd: abstract how prepared folios are recorded KVM: guest_memfd: let kvm_gmem_populate() operate only on private gfns KVM: extend kvm_range_has_memory_attributes() to check subset of attributes KVM: cleanup and add shortcuts to kvm_range_has_memory_attributes() KVM: guest_memfd: move check for already-populated page to common code KVM: remove kvm_arch_gmem_prepare_needed() KVM: guest_memfd: make kvm_gmem_prepare_folio() operate on a single struct kvm KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest KVM: guest_memfd: return locked folio from __kvm_gmem_get_pfn KVM: rename CONFIG_HAVE_KVM_GMEM_* to CONFIG_HAVE_KVM_ARCH_GMEM_* KVM: guest_memfd: do not go through struct page KVM: guest_memfd: delay folio_mark_uptodate() until after successful preparation KVM: guest_memfd: return folio from __kvm_gmem_get_pfn() KVM: x86: disallow pre-fault for SNP VMs before initialization KVM: Documentation: Fix title underline too short warning KVM: x86: Eliminate log spam from limited APIC timer periods
2024-08-02x86/tsc: Check for sockets instead of CPUs to make code match commentPaul E. McKenney1-1/+1
The unsynchronized_tsc() eventually checks num_possible_cpus(), and if the system is non-Intel and the number of possible CPUs is greater than one, assumes that TSCs are unsynchronized. This despite the comment saying "assume multi socket systems are not synchronized", that is, socket rather than CPU. This behavior was preserved by commit 8fbbc4b45ce3 ("x86: merge tsc_init and clocksource code") and by the previous relevant commit 7e69f2b1ead2 ("clocksource: Remove the update callback"). The clocksource drivers were added by commit 5d0cf410e94b ("Time: i386 Clocksource Drivers") back in 2006, and the comment still said "socket" rather than "CPU". Therefore, bravely (and perhaps foolishly) make the code match the comment. Note that it is possible to bypass both code and comment by booting with tsc=reliable, but this also disables the clocksource watchdog, which is undesirable when trust in the TSC is strictly limited. Reported-by: Zhengxu Chen <[email protected]> Reported-by: Danielle Costantino <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-02Merge branch 'kvm-fixes' into HEADPaolo Bonzini7-20/+24
* fix latent bug in how usage of large pages is determined for confidential VMs * fix "underline too short" in docs * eliminate log spam from limited APIC timer periods * disallow pre-faulting of memory before SEV-SNP VMs are initialized * delay clearing and encrypting private memory until it is added to guest page tables * this change also enables another small cleanup: the checks in SNP_LAUNCH_UPDATE that limit it to non-populated, private pages can now be moved in the common kvm_gmem_populate() function
Powered by cgit, Gruvboxed by Blaster4385.