aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-10-26riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENTChristoph Hellwig1-1/+0
RISCV_NONSTANDARD_CACHE_OPS is also used for the pmem cache maintenance helpers, which are built into the kernel unconditionally. Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2023-10-25powerpc: Remove initialisation of readposMatthew Wilcox (Oracle)1-1/+0
While powerpc doesn't use the seq_buf readpos, it did explicitly initialise it for no good reason. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Christoph Hellwig <[email protected]> Cc: Justin Stitt <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Michael Ellerman <[email protected]> Reviewed-by: Kees Cook <[email protected]> Fixes: d0ed46b60396 ("tracing: Move readpos from seq_buf to trace_seq") Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-10-25Merge tag 'v6.7-rockchip-dts64-2' of ↵Arnd Bergmann7-2/+669
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt One new board the Turing RK1 system on module. Support for DFI (DDR performance monitoring) for rk3588, rk3568 and an enable-fix for rk3399 as well as some small fixups for the RGB30 handheld (non-existent uart and better vpll frequency). * tag 'v6.7-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: Add Turing RK1 SoM support dt-bindings: arm: rockchip: Add Turing RK1 dt-bindings: vendor-prefixes: add turing arm64: dts: rockchip: Add DFI to rk3588s arm64: dts: rockchip: Add DFI to rk356x arm64: dts: rockchip: Always enable DFI on rk3399 arm64: dts: rockchip: Remove UART2 from RGB30 arm64: dts: rockchip: Update VPLL Frequency for RGB30 Link: https://lore.kernel.org/r/2777623.BEx9A2HvPv@phil Signed-off-by: Arnd Bergmann <[email protected]>
2023-10-25Merge tag 'ti-k3-dt-for-v6.7-part2' of ↵Arnd Bergmann13-25/+2666
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/dt TI K3 device-tree updates for v6.7 - part 2 Second round of few DT updates for K3 platforms. These have been in linux-next for a few days without issues. Most of the additions is for newer AM62P SoC dtsi bringing support on par with rest of AM62x family. New features: AM62P SoCs: Support for wide range of peripherals such as eMMC/SD, CPSW Ethernet, OSPI, etc similar to AM62 J721s2/J784s4/AM69 SoCs: Display support via DP and HDMI interfaces and associated SerDes support AM654 EVM/IDK: ICSSG/PRU based industrial Ethernet support * tag 'ti-k3-dt-for-v6.7-part2' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: arm64: dts: ti: k3-am654-idk: Add ICSSG Ethernet ports arm64: dts: ti: k3-am654-icssg2: add ICSSG2 Ethernet support arm64: dts: ti: k3-am65-main: Add ICSSG IEP nodes arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM arm64: dts: ti: k3-am62p: Add nodes for more IPs arm64: dts: ti: k3-am69-sk: Add DP and HDMI support arm64: dts: ti: k3-j784s4-evm: Enable DisplayPort-0 arm64: dts: ti: k3-j784s4-main: Add DSS and DP-bridge node arm64: dts: ti: k3-j784s4-main: Add WIZ and SERDES PHY nodes arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2023-10-25Merge tag 'arm-soc/for-6.7/devicetree' of ↵Arnd Bergmann24-34/+269
https://github.com/Broadcom/stblinux into soc/dt This pull request contains Broadcom ARM-based SoCs changes for 6.7, please pull the following: - Rafal makes a number of updates to the BCM5301X (Northstar) SoCs DTS to set MAC addresses for D-LInk DIR-885L, Asus, RT-AC87U, he relicenses parts of the DTSI to GPL 2.0+ / MIT, and finally fixes a number of Ethernet switch ports properties to enable/disable ports adequately. * tag 'arm-soc/for-6.7/devicetree' of https://github.com/Broadcom/stblinux: ARM: dts: BCM5301X: Set switch ports for Linksys EA9200 ARM: dts: BCM5301X: Set fixed-link for extra Netgear R8000 CPU ports ARM: dts: BCM5301X: Explicitly disable unused switch CPU ports ARM: dts: BCM5301X: Relicense Vivek's code to the GPL 2.0+ / MIT ARM: dts: BCM5301X: Relicense Felix's code to the GPL 2.0+ / MIT ARM: dts: BCM5301X: Set MAC address for Asus RT-AC87U ARM: dts: BCM5301X: Set MACs for D-Link DIR-885L Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2023-10-25Merge tag 'samsung-dt-6.7-2' of ↵Arnd Bergmann1-4/+4
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt Samsung DTS ARM changes for v6.7, part two Two minor improvements for Midas boards (Exynos4412, e.g. Samsung Galaxy S3): 1. Correct the middle hardware key to emit KEY_OK instead of KEY_MENU, because there is already separate touchkey providing KEY_MENU and both label and node name suggests this should be KEY_OK. 2. Use defines for other key input constants. * tag 'samsung-dt-6.7-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: samsung: exynos4412-midas: use Linux event codes for input keys ARM: dts: samsung: exynos4412-midas: fix key-ok event code Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2023-10-25sh: bios: Revive earlyprintk supportGeert Uytterhoeven1-0/+11
The SuperH BIOS earlyprintk code is protected by CONFIG_EARLY_PRINTK. However, when this protection was added, it was missed that SuperH no longer defines an EARLY_PRINTK config symbol since commit e76fe57447e88916 ("sh: Remove old early serial console code V2"), so BIOS earlyprintk can no longer be used. Fix this by reviving the EARLY_PRINTK config symbol. Fixes: d0380e6c3c0f6edb ("early_printk: consolidate random copies of identical code") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/c40972dfec3dcc6719808d5df388857360262878.1697708489.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
2023-10-25sh: machvec: Remove custom ioport_{un,}map()Arnd Bergmann3-19/+3
These functions were only used on the microdev board that is now gone, so remove them to simplify the ioport handling. This could be further simplified to use the generic I/O port accessors now. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
2023-10-25sh: Remove superhyway bus supportArnd Bergmann4-180/+0
The superhyway bus driver was only referenced on SH4-202, which is now gone, so remove it all as well. I could find no trace of anything ever calling superhyway_register_driver(), not in the git history but also not on the web, so I assume this has never served any purpose on mainline kernels. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
2023-10-25sh: Remove unused SH4-202 supportArnd Bergmann4-322/+0
This early prototype of the SH4 CPU was only used in the "microdev" board that is now removed, so all of the SH4-202 supoprt can also be removed. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
2023-10-25sh: Remove stale microdev boardArnd Bergmann10-754/+1
This board was an early prototype platform for early SH4 CPUs and related to the already removed SH5 cayman platform. The microdev board itself has been kept in the tree for this long despite being in a bad shape even 20 years ago when it got merged, with no working PCI support and ugly workarounds for its I/O port implementation that try to emulate PC style peripheral access despite being quite different in reality. As far as I can tell, the ethernet, display, USB and PCI devices on it already broke at some point (afbb9d8d5266b, 46bc85872040a), so I think we can just removeit entirely. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
2023-10-25Revert "Merge branch 'mv88e6xxx-dsa-bindings'"Jakub Kicinski20-330/+345
This reverts the following commits: commit 53313ed25ba8 ("dt-bindings: marvell: Add Marvell MV88E6060 DSA schema") commit 0f35369b4efe ("dt-bindings: marvell: Rewrite MV88E6xxx in schema") commit 605a5f5d406d ("ARM64: dts: marvell: Fix some common switch mistakes") commit bfedd8423643 ("ARM: dts: nxp: Fix some common switch mistakes") commit 2b83557a588f ("ARM: dts: marvell: Fix some common switch mistakes") commit ddae07ce9bb3 ("dt-bindings: net: mvusb: Fix up DSA example") commit b5ef61718ad7 ("dt-bindings: net: dsa: Require ports or ethernet-ports") As repoted by Vladimir, it breaks boot on the Turris MOX board. Link: https://lore.kernel.org/all/20231025093632.fb2qdtunzaznd73z@skbuf/ Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-25hexagon: Remove unusable symbols from the ptrace.h uapiThomas Huth2-13/+25
Kernel-internal prototypes, references to current_thread_info() and code hidden behind a CONFIG_HEXAGON_ARCH_VERSION switch are certainly not usable in userspace, so this should not reside in a uapi header. Move the code into an internal version of ptrace.h instead. Signed-off-by: Thomas Huth <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-10-25s390: delete the unused store_prefix() functionIlya Leoshkevich1-8/+0
Its last usage was deleted in commit 4df29d2b9024 ("s390/smp: rework absolute lowcore access"). Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Ilya Leoshkevich <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/cmma: fix handling of swapper_pg_dir and invalid_pg_dirHeiko Carstens1-0/+6
If the cmma no-dat feature is available the kernel page tables are walked to identify and mark all pages which are used for address translation (all region, segment, and page tables). In a subsequent loop all other pages are marked as "no-dat" pages with the ESSA instruction. This information is visible to the hypervisor, so that the hypervisor can optimize purging of guest TLB entries. All pages used for swapper_pg_dir and invalid_pg_dir are incorrectly marked as no-dat, which in turn can result in incorrect guest TLB flushes. Fix this by marking those pages correctly as being used for DAT. Cc: <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/cmma: fix detection of DAT pagesHeiko Carstens1-3/+3
If the cmma no-dat feature is available the kernel page tables are walked to identify and mark all pages which are used for address translation (all region, segment, and page tables). In a subsequent loop all other pages are marked as "no-dat" pages with the ESSA instruction. This information is visible to the hypervisor, so that the hypervisor can optimize purging of guest TLB entries. The initial loop however is incorrect: only the first three of the four pages which belong to segment and region tables will be marked as being used for DAT. The last page is incorrectly marked as no-dat. This can result in incorrect guest TLB flushes. Fix this by simply marking all four pages. Cc: <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/pai_crypto: remove per-cpu variable assignement in event initializationThomas Richter1-1/+0
Function paicrypt_event_init() initializes the PMU device driver specific details for an event. It is called once per event creation. The function paicrypt_event_init() is not necessarily executed on that CPU the event will be used for. When an event is activated, function paicrypt_start() is used to start the event on that CPU. The per CPU data structure struct paicrypt_map has a pointer to the event which is active for a particular CPU. This pointer is set in function paicrypt_start() to point to the currently installed event. There is no need to also set this pointer in function paicrypt_event_init() where is might be assigned to the wrong CPU. Therefore remove this assignment in paicrypt_event_init(). Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/pai: initialize event count once at initializationThomas Richter2-2/+0
Event count value is initialized and set to zero in function paicrypt_start(). This function is called once per CPU when an event is started on that CPU. This leads to event count value being set to zero as many times as there are online CPUs. This is not necessary. The event count value is bound to the event and it is sufficient to initialize the event counter once at event creation time. This is done when the event structure is dynamicly allocated with __GFP_ZERO flag. This sets member count to zero. Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/pai_crypto: use PERF_ATTACH_TASK define for per task detectionThomas Richter2-2/+2
Use define PERF_ATTACH_TASK bit in event->attach_state to determine system wide invocation or per task invocation in event initialization. This bit is set in common code and before calling PMU device driver specific event initialization. It is set once and never changes. It is save to use and also in sync with other PMU specific code. No functional change. Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25s390/mm: add missing arch_set_page_dat() call to gmap allocationsHeiko Carstens2-6/+19
If the cmma no-dat feature is available all pages that are not used for dynamic address translation are marked as "no-dat" with the ESSA instruction. This information is visible to the hypervisor, so that the hypervisor can optimize purging of guest TLB entries. This also means that pages which are used for dynamic address translation must not be marked as "no-dat", since the hypervisor may then incorrectly not purge guest TLB entries. Region, segment, and page tables allocated within the gmap code are incorrectly marked as "no-dat", since an explicit call to arch_set_page_dat() is missing, which would remove the "no-dat" mark. In order to fix this add a new gmap_alloc_crst() function which should be used to allocate region and segment tables, and which also calls arch_set_page_dat(). Also add the arch_set_page_dat() call to page_table_alloc_pgste(). Cc: <[email protected]> Reviewed-by: Claudio Imbrenda <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-25ARM64: dts: marvell: Fix some common switch mistakesLinus Walleij7-167/+164
Fix some errors in the Marvell MV88E6xxx switch descriptions: - The top node had no address size or cells. - switch0@0 is not OK, should be ethernet-switch@0. - ports should be ethernet-ports - port@0 should be ethernet-port@0 - PHYs should be named ethernet-phy@ Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-10-25ARM: dts: nxp: Fix some common switch mistakesLinus Walleij5-70/+70
Fix some errors in the Marvell MV88E6xxx switch descriptions: - switch0@0 is not OK, should be ethernet-switch@0 - ports should be ethernet-ports - port should be ethernet-port - phy should be ethernet-phy Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-10-25ARM: dts: marvell: Fix some common switch mistakesLinus Walleij8-108/+96
Fix some errors in the Marvell MV88E6xxx switch descriptions: - The top node had no address size or cells. - switch0@0 is not OK, should be ethernet-switch@0. - The ports node should be named ethernet-ports - The ethernet-ports node should have port@0 etc children, no plural "ports" in the children. - Ports should be named ethernet-port@0 etc - PHYs should be named ethernet-phy@0 etc This serves as an example of fixes needed for introducing a schema for the bindings, but the patch can simply be applied. Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-10-25powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptesAneesh Kumar K.V1-10/+22
With commit 9fee28baa601 ("powerpc: implement the new page table range API") we added set_ptes to powerpc architecture. The implementation included calling arch_enter/leave_lazy_mmu() calls. The patch removes the usage of arch_enter/leave_lazy_mmu() because set_pte is not supposed to be used when updating a pte entry. Powerpc architecture uses this rule to skip the expensive tlb invalidate which is not needed when you are setting up the pte for the first time. See commit 56eecdb912b5 ("mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit") for more details The patch also makes sure we are not using the interface to update a valid/present pte entry by adding VM_WARN_ON check all the ptes we are setting up. Furthermore, we add a comment to set_pte_filter to clarify it can only update folio-related flags and cannot filter pfn specific details in pte filtering. Removal of arch_enter/leave_lazy_mmu() also will avoid nesting of these functions that are not supported. For ex: remap_pte_range() -> arch_enter_lazy_mmu() -> set_ptes() -> arch_enter_lazy_mmu() -> arch_leave_lazy_mmu() -> arch_leave_lazy_mmu() Fixes: 9fee28baa601 ("powerpc: implement the new page table range API") Signed-off-by: "Aneesh Kumar K.V" <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-10-25powerpc/vmcore: Add MMU information to vmcoreinfoAditya Gupta1-0/+3
Since below commit, address mapping for vmemmap has changed for Radix MMU, where address mapping is stored in kernel page table itself, instead of earlier used 'vmemmap_list'. commit 368a0590d954 ("powerpc/book3s64/vmemmap: switch radix to use a different vmemmap handling function") Hence with upstream kernel, in case of Radix MMU, makedumpfile fails to do address translation for vmemmap addresses, as it depended on vmemmap_list, which can now be empty. While fixing the address translation in makedumpfile, it was identified that currently makedumpfile cannot distinguish between Hash MMU and Radix MMU, unless VMLINUX is passed with -x flag to makedumpfile. And hence fails to assign offsets and shifts correctly (such as in L4 to PGDIR offset calculation in makedumpfile). For getting the MMU, makedumpfile uses `cur_cpu_spec.mmu_features`. Add `cur_cpu_spec` symbol and offset of `mmu_features` in the `cpu_spec` struct, to VMCOREINFO, so that makedumpfile can assign the offsets correctly, without needing a VMLINUX. Also, even along with `cur_cpu_spec->mmu_features` makedumpfile has to depend on the 'MMU_FTR_TYPE_RADIX' flag in mmu_features, implying kernel developers need to be cautious of changes to 'MMU_FTR_*' defines. A more stable approach was suggested in the below thread by contributors: https://lore.kernel.org/linuxppc-dev/[email protected]/ The suggestion was to add whether 'RADIX_MMU' is enabled in vmcoreinfo This patch also implements the suggestion, by adding 'RADIX_MMU' in vmcoreinfo, which makedumpfile can use to get whether the crashed system had RADIX MMU (in which case 'NUMBER(RADIX_MMU)=1') or not (in which case 'NUMBER(RADIX_MMU)=0') Fixes: 368a0590d954 ("powerpc/book3s64/vmemmap: switch radix to use a different vmemmap handling function") Reported-by: Sachin Sant <[email protected]> Signed-off-by: Aditya Gupta <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
2023-10-25Revert "powerpc: add `cur_cpu_spec` symbol to vmcoreinfo"Michael Ellerman1-2/+0
This reverts commit 7135b921b32966d7602ede396b7286d372aee63f. I applied this commit prematurely while there was still discussion ongoing. Revert it so the final patch can be applied cleanly. Signed-off-by: Michael Ellerman <[email protected]>
2023-10-25KVM: arm64: Handle AArch32 SPSR_{irq,abt,und,fiq} as RAZ/WIMarc Zyngier2-3/+17
When trapping accesses from a NV guest that tries to access SPSR_{irq,abt,und,fiq}, make sure we handle them as RAZ/WI, as if AArch32 wasn't implemented. This involves a bit of repainting to make the visibility handler more generic. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-25KVM: arm64: Do not let a L1 hypervisor access the *32_EL2 sysregsMarc Zyngier1-4/+4
DBGVCR32_EL2, DACR32_EL2, IFSR32_EL2 and FPEXC32_EL2 are required to UNDEF when AArch32 isn't implemented, which is definitely the case when running NV. Given that this is the only case where these registers can trap, unconditionally inject an UNDEF exception. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Reviewed-by: Eric Auger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-25KVM: arm64: Refine _EL2 system register list that require trap reinjectionMiguel Luis1-6/+71
Implement a fine grained approach in the _EL2 sysreg range instead of the current wide cast trap. This ensures that we don't mistakenly inject the wrong exception into the guest. [maz: commit message massaging, dropped secure and AArch32 registers from the list] Fixes: d0fc0a2519a6 ("KVM: arm64: nv: Add trap forwarding for HCR_EL2") Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Miguel Luis <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-25arm64: Add missing _EL2 encodingsMiguel Luis1-0/+30
Some _EL2 encodings are missing. Add them. Signed-off-by: Miguel Luis <[email protected]> Reviewed-by: Eric Auger <[email protected]> [maz: dropped secure encodings] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-25arm64: Add missing _EL12 encodingsMiguel Luis1-0/+11
Some _EL12 encodings are missing. Add them. Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Miguel Luis <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: PMU: Allow userspace to limit PMCR_EL0.N for the guestReiji Watanabe1-4/+42
KVM does not yet support userspace modifying PMCR_EL0.N (With the previous patch, KVM ignores what is written by userspace). Add support userspace limiting PMCR_EL0.N. Disallow userspace to set PMCR_EL0.N to a value that is greater than the host value as KVM doesn't support more event counters than what the host HW implements. Also, make this register immutable after the VM has started running. To maintain the existing expectations, instead of returning an error, KVM returns a success for these two cases. Finally, ignore writes to read-only bits that are cleared on vCPU reset, and RES{0,1} bits (including writable bits that KVM doesn't support yet), as those bits shouldn't be modified (at least with the current KVM). Co-developed-by: Marc Zyngier <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Reiji Watanabe <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: Sanitize PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR} before first runRaghavendra Rao Ananta2-1/+12
For unimplemented counters, the registers PM{C,I}NTEN{SET,CLR} and PMOVS{SET,CLR} are expected to have the corresponding bits RAZ. Hence to ensure correct KVM's PMU emulation, mask out the RES0 bits. Defer this work to the point that userspace can no longer change the number of advertised PMCs. Signed-off-by: Raghavendra Rao Ananta <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: Add {get,set}_user for PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR}Raghavendra Rao Ananta1-6/+45
For unimplemented counters, the bits in PM{C,I}NTEN{SET,CLR} and PMOVS{SET,CLR} registers are expected to RAZ. To honor this, explicitly implement the {get,set}_user functions for these registers to mask out unimplemented counters for userspace reads and writes. Co-developed-by: Marc Zyngier <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Oliver: drop unnecessary locking] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: PMU: Set PMCR_EL0.N for vCPU based on the associated PMURaghavendra Rao Ananta3-15/+37
The number of PMU event counters is indicated in PMCR_EL0.N. For a vCPU with PMUv3 configured, the value is set to the same value as the current PE on every vCPU reset. Unless the vCPU is pinned to PEs that has the PMU associated to the guest from the initial vCPU reset, the value might be different from the PMU's PMCR_EL0.N on heterogeneous PMU systems. Fix this by setting the vCPU's PMCR_EL0.N to the PMU's PMCR_EL0.N value. Track the PMCR_EL0.N per guest, as only one PMU can be set for the guest (PMCR_EL0.N must be the same for all vCPUs of the guest), and it is convenient for updating the value. To achieve this, the patch introduces a helper, kvm_arm_pmu_get_max_counters(), that reads the maximum number of counters from the arm_pmu associated to the VM. Make the function global as upcoming patches will be interested to know the value while setting the PMCR.N of the guest from userspace. KVM does not yet support userspace modifying PMCR_EL0.N. The following patch will add support for that. Reviewed-by: Sebastian Ott <[email protected]> Co-developed-by: Marc Zyngier <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Reiji Watanabe <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: PMU: Add a helper to read a vCPU's PMCR_EL0Reiji Watanabe3-11/+19
Add a helper to read a vCPU's PMCR_EL0, and use it whenever KVM reads a vCPU's PMCR_EL0. Currently, the PMCR_EL0 value is tracked per vCPU. The following patches will make (only) PMCR_EL0.N track per guest. Having the new helper will be useful to combine the PMCR_EL0.N field (tracked per guest) and the other fields (tracked per vCPU) to provide the value of PMCR_EL0. No functional change intended. Reviewed-by: Sebastian Ott <[email protected]> Signed-off-by: Reiji Watanabe <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: Select default PMU in KVM_ARM_VCPU_INIT handlerReiji Watanabe2-12/+23
Future changes to KVM's sysreg emulation will rely on having a valid PMU instance to determine the number of implemented counters (PMCR_EL0.N). This is earlier than when userspace is expected to modify the vPMU device attributes, where the default is selected today. Select the default PMU when handling KVM_ARM_VCPU_INIT such that it is available in time for sysreg emulation. Reviewed-by: Sebastian Ott <[email protected]> Co-developed-by: Marc Zyngier <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Reiji Watanabe <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Oliver: rewrite changelog] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24net: dsa: Use conduit and user termsFlorian Fainelli1-1/+1
Use more inclusive terms throughout the DSA subsystem by moving away from "master" which is replaced by "conduit" and "slave" which is replaced by "user". No functional changes. Acked-by: Rob Herring <[email protected]> Acked-by: Stephen Hemminger <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-24Merge tag 'mm-hotfixes-stable-2023-10-24-09-40' of ↵Linus Torvalds2-7/+14
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "20 hotfixes. 12 are cc:stable and the remainder address post-6.5 issues or aren't considered necessary for earlier kernel versions" * tag 'mm-hotfixes-stable-2023-10-24-09-40' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: maple_tree: add GFP_KERNEL to allocations in mas_expected_entries() selftests/mm: include mman header to access MREMAP_DONTUNMAP identifier mailmap: correct email aliasing for Oleksij Rempel mailmap: map Bartosz's old address to the current one mm/damon/sysfs: check DAMOS regions update progress from before_terminate() MAINTAINERS: Ondrej has moved kasan: disable kasan_non_canonical_hook() for HW tags kasan: print the original fault addr when access invalid shadow hugetlbfs: close race between MADV_DONTNEED and page fault hugetlbfs: extend hugetlb_vma_lock to private VMAs hugetlbfs: clear resv_map pointer if mmap fails mm: zswap: fix pool refcount bug around shrink_worker() mm/migrate: fix do_pages_move for compat pointers riscv: fix set_huge_pte_at() for NAPOT mappings when a swap entry is set riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking mmap: fix error paths with dup_anon_vma() mmap: fix vma_iterator in error path of vma_merge() mm: fix vm_brk_flags() to not bail out while holding lock mm/mempolicy: fix set_mempolicy_home_node() previous VMA pointer mm/page_alloc: correct start page when guard page debug is enabled
2023-10-24KVM: arm64: Add PMU event filter bits required if EL3 is implementedOliver Upton1-2/+13
Suzuki noticed that KVM's PMU emulation is oblivious to the NSU and NSK event filter bits. On systems that have EL3 these bits modify the filter behavior in non-secure EL0 and EL1, respectively. Even though the kernel doesn't use these bits, it is entirely possible some other guest OS does. Additionally, it would appear that these and the M bit are required by the architecture if EL3 is implemented. Allow the EL3 event filter bits to be set if EL3 is advertised in the guest's ID register. Implement the behavior of NSU and NSK according to the pseudocode, and entirely ignore the M bit for perf event creation. Reported-by: Suzuki K Poulose <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: Make PMEVTYPER<n>_EL0.NSH RES0 if EL2 isn't advertisedOliver Upton2-9/+20
The NSH bit, which filters event counting at EL2, is required by the architecture if an implementation has EL2. Even though KVM doesn't support nested virt yet, it makes no effort to hide the existence of EL2 from the ID registers. Userspace can, however, change the value of PFR0 to hide EL2. Align KVM's sysreg emulation with the architecture and make NSH RES0 if EL2 isn't advertised. Keep in mind the bit is ignored when constructing the backing perf event. While at it, build the event type mask using explicit field definitions instead of relying on ARMV8_PMU_EVTYPE_MASK. KVM probably should've been doing this in the first place, as it avoids changes to the aforementioned mask affecting sysreg emulation. Reviewed-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24KVM: arm64: PMU: Introduce helpers to set the guest's PMUReiji Watanabe1-15/+35
Introduce new helper functions to set the guest's PMU (kvm->arch.arm_pmu) either to a default probed instance or to a caller requested one, and use it when the guest's PMU needs to be set. These helpers will make it easier for the following patches to modify the relevant code. No functional change intended. Reviewed-by: Sebastian Ott <[email protected]> Signed-off-by: Reiji Watanabe <[email protected]> Signed-off-by: Raghavendra Rao Ananta <[email protected]> Reviewed-by: Eric Auger <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2023-10-24x86/defconfig: Enable CONFIG_DEBUG_ENTRY=yIngo Molnar2-0/+2
A bug was recently found via CONFIG_DEBUG_ENTRY=y, and the x86 tree kinda is the main source of changes to the x86 entry code, so enable this debug option by default in our defconfigs. Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected]
2023-10-24ARM: dts: BCM5301X: Set switch ports for Linksys EA9200Rafał Miłecki1-0/+38
This patch was developed as OpenWrt downstream change and was recently confirmed to work as expected. Tested-by: Rani Hod <[email protected]> Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]>
2023-10-24arm64: module: Fix PLT counting when CONFIG_RANDOMIZE_BASE=nMaria Yu1-6/+0
The counting of module PLTs has been broken when CONFIG_RANDOMIZE_BASE=n since commit: 3e35d303ab7d22c4 ("arm64: module: rework module VA range selection") Prior to that commit, when CONFIG_RANDOMIZE_BASE=n, the kernel image and all modules were placed within a 128M region, and no PLTs were necessary for B or BL. Hence count_plts() and partition_branch_plt_relas() skipped handling B and BL when CONFIG_RANDOMIZE_BASE=n. After that commit, modules can be placed anywhere within a 2G window regardless of CONFIG_RANDOMIZE_BASE, and hence PLTs may be necessary for B and BL even when CONFIG_RANDOMIZE_BASE=n. Unfortunately that commit failed to update count_plts() and partition_branch_plt_relas() accordingly. Due to this, module_emit_plt_entry() may fail if an insufficient number of PLT entries have been reserved, resulting in modules failing to load with -ENOEXEC. Fix this by counting PLTs regardless of CONFIG_RANDOMIZE_BASE in count_plts() and partition_branch_plt_relas(). Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection") Signed-off-by: Maria Yu <[email protected]> Cc: <[email protected]> # 6.5.x Acked-by: Ard Biesheuvel <[email protected]> Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection") Reviewed-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2023-10-24arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helperJames Morse1-1/+1
ACPI, irqchip and the architecture code all inspect the MADT enabled bit for a GICC entry in the MADT. The addition of an 'online capable' bit means all these sites need updating. Move the current checks behind a helper to make future updates easier. Signed-off-by: James Morse <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Signed-off-by: "Russell King (Oracle)" <[email protected]> Acked-by: "Rafael J. Wysocki" <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2023-10-24x86/microcode/intel: Add a minimum required revision for late loadingAshok Raj2-5/+35
In general users, don't have the necessary information to determine whether late loading of a new microcode version is safe and does not modify anything which the currently running kernel uses already, e.g. removal of CPUID bits or behavioural changes of MSRs. To address this issue, Intel has added a "minimum required version" field to a previously reserved field in the microcode header. Microcode updates should only be applied if the current microcode version is equal to, or greater than this minimum required version. Thomas made some suggestions on how meta-data in the microcode file could provide Linux with information to decide if the new microcode is suitable candidate for late loading. But even the "simpler" option requires a lot of metadata and corresponding kernel code to parse it, so the final suggestion was to add the 'minimum required version' field in the header. When microcode changes visible features, microcode will set the minimum required version to its own revision which prevents late loading. Old microcode blobs have the minimum revision field always set to 0, which indicates that there is no information and the kernel considers it unsafe. This is a pure OS software mechanism. The hardware/firmware ignores this header field. For early loading there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect. The check is always enabled, but by default not enforced. It can be enforced via Kconfig or kernel command line. If enforced, the kernel refuses to late load microcode with a minimum required version field which is zero or when the currently loaded microcode revision is smaller than the minimum required revision. If not enforced the load happens independent of the revision check to stay compatible with the existing behaviour, but it influences the decision whether the kernel is tainted or not. If the check signals that the late load is safe, then the kernel is not tainted. Early loading is not affected by this. [ tglx: Massaged changelog and fixed up the implementation ] Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Ashok Raj <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-24x86/microcode: Prepare for minimal revision checkThomas Gleixner5-6/+44
Applying microcode late can be fatal for the running kernel when the update changes functionality which is in use already in a non-compatible way, e.g. by removing a CPUID bit. There is no way for admins which do not have access to the vendors deep technical support to decide whether late loading of such a microcode is safe or not. Intel has added a new field to the microcode header which tells the minimal microcode revision which is required to be active in the CPU in order to be safe. Provide infrastructure for handling this in the core code and a command line switch which allows to enforce it. If the update is considered safe the kernel is not tainted and the annoying warning message not emitted. If it's enforced and the currently loaded microcode revision is not safe for late loading then the load is aborted. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-24x86/microcode: Handle "offline" CPUs correctlyThomas Gleixner4-6/+113
Offline CPUs need to be parked in a safe loop when microcode update is in progress on the primary CPU. Currently, offline CPUs are parked in mwait_play_dead(), and for Intel CPUs, its not a safe instruction, because the MWAIT instruction can be patched in the new microcode update that can cause instability. - Add a new microcode state 'UCODE_OFFLINE' to report status on per-CPU basis. - Force NMI on the offline CPUs. Wake up offline CPUs while the update is in progress and then return them back to mwait_play_dead() after microcode update is complete. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-24x86/apic: Provide apic_force_nmi_on_cpu()Thomas Gleixner5-1/+16
When SMT siblings are soft-offlined and parked in one of the play_dead() variants they still react on NMI, which is problematic on affected Intel CPUs. The default play_dead() variant uses MWAIT on modern CPUs, which is not guaranteed to be safe when updated concurrently. Right now late loading is prevented when not all SMT siblings are online, but as they still react on NMI, it is possible to bring them out of their park position into a trivial rendezvous handler. Provide a function which allows to do that. I does sanity checks whether the target is in the cpus_booted_once_mask and whether the APIC driver supports it. Mark X2APIC and XAPIC as capable, but exclude 32bit and the UV and NUMACHIP variants as that needs feedback from the relevant experts. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.