summaryrefslogtreecommitdiff
path: root/arch/riscv
AgeCommit message (Collapse)Author
2022-01-06RISC-V: KVM: Add v0.1 replacement SBI extensions defined in v0.2Atish Patra
The SBI v0.2 contains some of the improved versions of required v0.1 extensions such as remote fence, timer and IPI. This patch implements those extensions. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com>
2022-01-06RISC-V: KVM: Add SBI v0.2 base extensionAtish Patra
SBI v0.2 base extension defined to allow backward compatibility and probing of future extensions. This is also the only mandatory SBI extension that must be implemented by SBI implementors. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com>
2022-01-06RISC-V: KVM: Reorganize SBI code by moving SBI v0.1 to its own fileAtish Patra
With SBI v0.2, there may be more SBI extensions in future. It makes more sense to group related extensions in separate files. Guest kernel will choose appropriate SBI version dynamically. Move the existing implementation to a separate file so that it can be removed in future without much conflict. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com>
2022-01-06RISC-V: KVM: Mark the existing SBI implementation as v0.1Atish Patra
The existing SBI specification impelementation follows v0.1 specification. The latest specification allows more scalability and performance improvements. Rename the existing implementation as v0.1 and provide a way to allow future extensions. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Anup Patel <anup.patel@wdc.com>
2022-01-06KVM: RISC-V: Use common KVM implementation of MMU memory cachesSean Christopherson
Use common KVM's implementation of the MMU memory caches, which for all intents and purposes is semantically identical to RISC-V's version, the only difference being that the common implementation will fall back to an atomic allocation if there's a KVM bug that triggers a cache underflow. RISC-V appears to have based its MMU code on arm64 before the conversion to the common caches in commit c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory caches"), despite having also copy-pasted the definition of KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE in kvm_types.h. Opportunistically drop the superfluous wrapper kvm_riscv_stage2_flush_cache(), whose name is very, very confusing as "cache flush" in the context of MMU code almost always refers to flushing hardware caches, not freeing unused software objects. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Anup Patel <anup.patel@wdc.com>
2022-01-05RISC-V: defconfigs: Remove redundant CONFIG_EFI=yPalmer Dabbelt
We've always had CONFIG_EFI as "def_bool y" so this has always been redundant. It's removed by savedefconfig, so drop it to keep things clean. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Remove redundant CONFIG_POWER_RESETPalmer Dabbelt
As of ab7fbad0c7d7 ("riscv: Fix unmet direct dependencies built based on SOC_VIRT") we select CONFIG_POWER_RESET=y along with CONFIG_SOC_VIRT, which is already in defconfig. This make setting CONFIG_POWER_RESET in the defconfigs redundant, so remove it to remain consistent with savedefconfig. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_BLK_DEV_BSGPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_BLK_DEV_BSG the same way savedefconfig does. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_SURFACE_PLATFORMSPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_SURFACE_PLATFORMS the same way savedefconfig does. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_MMCPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_MMC the same way savedefconfig does. This only touches the rv64 defconfig because rv32_defconfig was already sorted correctly. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_PTP_1588_CLOCKPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_PTP_1588_CLOCK the same way savedefconfig does. This only touches the rv64 defconfig because rv32_defconfig was already sorted correctly. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_SOC_POLARFIREPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_SOC_POLARFIRE the same way savedefconfig does. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_SYSFS_SYSCALLPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_SYSFS_SYSCALL the same way savedefconfig does. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Sort CONFIG_BPF_SYSCALLPalmer Dabbelt
This should have no functional change, it just sorts CONFIG_BPF_SYSCALL the same way savedefconfig does. Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOWPalmer Dabbelt
For non-relocatable kernels we need to be able to link the kernel at approximately PAGE_OFFSET, thus requiring medany (as medlow requires the code to be linked within 2GiB of 0). The inverse doesn't apply, though: since medany code can be linked anywhere it's fine to link it close to 0, so we can support the smaller memory config. Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32") Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05RISC-V: defconfigs: Set CONFIG_FB=y, for FB consolePalmer Dabbelt
We have CONFIG_FRAMEBUFFER_CONSOLE=y in the defconfigs, but that depends on CONFIG_FB so it's not actually getting set. I'm assuming most users on real systems want a framebuffer console, so this enables CONFIG_FB to allow that to take effect. Fixes: 33c57c0d3c67 ("RISC-V: Add a basic defconfig") Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: mm: Enable PMD split page table lock for RV64Kefeng Wang
After commit 1355c31eeb7e ("asm-generic: pgalloc: provide generic pmd_alloc_one() and pmd_free_one()"), the main part to support PMD split page table lock is in asm-generic/pgalloc.h. The only change is add pgtable_pmd_page_ctor() into alloc_pmd_late(), then we could enable ARCH_ENABLE_SPLIT_PMD_PTLOCK for RV64. Reviewed-by: Alexandre Ghiti <alex@ghiti.fr> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: Make vmalloc/vmemmap end equal to the start of the next regionAlexandre Ghiti
We used to define VMALLOC_END equal to the start of the next region *minus one* which is inconsistent with the use of this define in the core code (for example, see the definitions of VMALLOC_TOTAL and is_vmalloc_addr). And then make the definition of VMEMMAP_END consistent with VMALLOC_END and all other regions actually. Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: switch to relative extable and other improvementsPalmer Dabbelt
Similar as other architectures such as arm64, x86 and so on, use offsets relative to the exception table entry values rather than absolute addresses for both the exception locationand the fixup. And recently, arm64 and x86 remove anonymous out-of-line fixups, we want to acchieve the same result.
2022-01-05riscv: vmlinux.lds.S|vmlinux-xip.lds.S: remove `.fixup` sectionJisheng Zhang
These are no longer necessary now that we have a more standard extable mechanism. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: extable: add a dedicated uaccess handlerJisheng Zhang
Inspired by commit 2e77a62cb3a6 ("arm64: extable: add a dedicated uaccess handler"), do similar to riscv to add a dedicated uaccess exception handler to update registers in exception context and subsequently return back into the function which faulted, so we remove the need for fixups specialized to each faulting instruction. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: add gpr-num.hJisheng Zhang
This defines the mapping from ABI names to X registers. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: extable: add `type` and `data` fieldsJisheng Zhang
This is a riscv port of commit d6e2cc564775 ("arm64: extable: add `type` and `data` fields"). Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: extable: consolidate definitionsJisheng Zhang
This is a riscv port of commit 819771cc2892 ("arm64: extable: consolidate definitions"). Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: lib: uaccess: fold fixups into bodyJisheng Zhang
uaccess functions such __asm_copy_to_user(), __arch_copy_from_user() and __clear_user() place their exception fixups in the `.fixup` section without any clear association with themselves. If we backtrace the fixup code, it will be symbolized as an offset from the nearest prior symbol. Similar as arm64 does, we must move fixups into the body of the functions themselves, after the usual fast-path returns. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: extable: use `ex` for `exception_table_entry`Jisheng Zhang
The var name "fixup" is a bit confusing, since this is a exception_table_entry. Use "ex" instead to refer to an entire entry. In subsequent patches we'll use `fixup` to refer to the fixup field specifically. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: extable: make fixup_exception() return boolJisheng Zhang
The return values of fixup_exception() and riscv_bpf_fixup_exception() represent a boolean condition rather than an error code, so it's better to return `bool` rather than `int`. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: bpf: move rv_bpf_fixup_exception signature to extable.hJisheng Zhang
This is to group riscv related extable related functions signature into one file. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: switch to relative exception tablesJisheng Zhang
Similar as other architectures such as arm64, x86 and so on, use offsets relative to the exception table entry values rather than absolute addresses for both the exception locationand the fixup. However, RISCV label difference will actually produce two relocations, a pair of R_RISCV_ADD32 and R_RISCV_SUB32. Take below simple code for example: $ cat test.S .section .text 1: nop .section __ex_table,"a" .balign 4 .long (1b - .) .previous $ riscv64-linux-gnu-gcc -c test.S $ riscv64-linux-gnu-readelf -r test.o Relocation section '.rela__ex_table' at offset 0x100 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000600000023 R_RISCV_ADD32 0000000000000000 .L1^B1 + 0 000000000000 000500000027 R_RISCV_SUB32 0000000000000000 .L0 + 0 The modpost will complain the R_RISCV_SUB32 relocation, so we need to patch modpost.c to skip this relocation for .rela__ex_table section. After this patch, the __ex_table section size of defconfig vmlinux is reduced from 7072 Bytes to 3536 Bytes. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: consolidate __ex_table constructionJisheng Zhang
Consolidate all the __ex_table constuction code with a _ASM_EXTABLE helper. There should be no functional change as a result of this patch. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-01-05riscv: remove unused __cmpxchg_user() macroJisheng Zhang
This macro is defined but not used, remove it. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c commit 077cdda764c7 ("net/mlx5e: TC, Fix memory leak with rules with internal port") commit 31108d142f36 ("net/mlx5: Fix some error handling paths in 'mlx5e_tc_add_fdb_flow()'") commit 4390c6edc0fb ("net/mlx5: Fix some error handling paths in 'mlx5e_tc_add_fdb_flow()'") https://lore.kernel.org/all/20211229065352.30178-1-saeed@kernel.org/ net/smc/smc_wr.c commit 49dc9013e34b ("net/smc: Use the bitmap API when applicable") commit 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock") bitmap_zero()/memset() is removed by the fix Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-27Merge tag 'efi-urgent-for-v5.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fix from Ard Biesheuvel: "Another EFI fix for v5.16: - Prevent missing prototype warning from breaking the build under CONFIG_WERROR=y" * tag 'efi-urgent-for-v5.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Move efifb_setup_from_dmi() prototype from arch headers
2021-12-17Merge tag 'riscv-for-linus-5.16-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A handful of DT updates for the SiFive HiFive Unmatched, that fix the regulator handling. These should stop some warning spew. - A pair of fixes for both the SiFive Hifive Unleashed and Unmatched, that correctly hook up the MMC card detect signal. * tag 'riscv-for-linus-5.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: dts: sifive unmatched: Link the tmp451 with its power supply riscv: dts: sifive unmatched: Fix regulator for board rev3 riscv: dts: sifive unmatched: Expose the PMIC sub-functions riscv: dts: sifive unmatched: Expose the board ID eeprom riscv: dts: sifive unmatched: Name gpio lines riscv: dts: unmatched: Add gpio card detect to mmc-spi-slot riscv: dts: unleashed: Add gpio card detect to mmc-spi-slot
2021-12-16riscv: dts: sifive unmatched: Link the tmp451 with its power supplyVincent Pelletier
Fixes the following probe warning: lm90 0-004c: Looking up vcc-supply from device tree lm90 0-004c: Looking up vcc-supply property in node /soc/i2c@10030000/temperature-sensor@4c failed lm90 0-004c: supply vcc not found, using dummy regulator Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-16riscv: dts: sifive unmatched: Fix regulator for board rev3Vincent Pelletier
The existing values are rejected by the da9063 regulator driver, as they are unachievable with the declared chip setup (non-merged vcore and bmem are unable to provide the declared curent). Fix voltages to match rev3 schematics, which also matches their boot-up configuration within the chip's available precision. Declare bcore1/bcore2 and bmem/bio as merged. Set ldo09 and ldo10 as always-on as their consumers are not declared but exist. Drop ldo current limits as there is no current limit feature for these regulators in the DA9063. Fixes warnings like: DA9063_LDO3: Operation of current configuration missing Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-16riscv: dts: sifive unmatched: Expose the PMIC sub-functionsVincent Pelletier
These sub-functions are available in the chip revision on this board, so expose them. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-16riscv: dts: sifive unmatched: Expose the board ID eepromVincent Pelletier
Mark it as read-only as it is factory-programmed with identifying information, and no executable nor configuration: - eth MAC address - board model (PCB version, BoM version) - board serial number Accidental modification would cause misidentification which could brick the board, so marking read-only seem like both a safe and non-constraining choice. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-16riscv: dts: sifive unmatched: Name gpio linesVincent Pelletier
Follow the pin descriptions given in the version 3 of the board schematics. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-12-16Merge tag 'jh7100-for-5.17' of https://github.com/esmil/linux into arm/newsocArnd Bergmann
Basic StarFive JH7100 RISC-V SoC support This adds support for the StarFive JH7100 RISC-V SoC. The SoC has many devices that need non-coherent DMA operations to work which isn't upstream yet[1], so this just adds basic support to boot up, get a serial console, blink an LED and reboot itself. Unlike the Allwinner D1 this chip doesn't use any extra pagetable bits, but instead the DDR RAM appears twice in the memory map, with and without the cache. The JH7100 is a test chip for the upcoming JH7110 and about 300 BeagleV Starlight Beta boards were sent out with them as part of a now cancelled BeagleBoard.org project. However StarFive has produced more of the JH7100s and will be selling VisionFive boards with them soon[2]. [1]: https://lore.kernel.org/linux-riscv/20210723214031.3251801-2-atish.patra@wdc.com/ [2]: https://www.cnx-software.com/2021/12/09/starfive-visionfive-single-board-computer-for-sale-accelerating-risc-v-ecosystem-development/ * tag 'jh7100-for-5.17' of https://github.com/esmil/linux: RISC-V: Add BeagleV Starlight Beta device tree RISC-V: Add initial StarFive JH7100 device tree serial: 8250_dw: Add StarFive JH7100 quirk dt-bindings: serial: snps-dw-apb-uart: Add JH7100 uarts pinctrl: starfive: Add pinctrl driver for StarFive SoCs dt-bindings: pinctrl: Add StarFive JH7100 bindings dt-bindings: pinctrl: Add StarFive pinctrl definitions reset: starfive-jh7100: Add StarFive JH7100 reset driver dt-bindings: reset: Add Starfive JH7100 reset bindings dt-bindings: reset: Add StarFive JH7100 reset definitions clk: starfive: Add JH7100 clock generator driver dt-bindings: clock: starfive: Add JH7100 bindings dt-bindings: clock: starfive: Add JH7100 clock definitions dt-bindings: interrupt-controller: Add StarFive JH7100 plic dt-bindings: timer: Add StarFive JH7100 clint RISC-V: Add StarFive SoC Kconfig option Link: https://lore.kernel.org/r/20211216164205.286138-1-kernel@esmil.dk Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-12-16RISC-V: Add BeagleV Starlight Beta device treeEmil Renner Berthing
Add initial device tree for the BeagleV Starlight Beta board. About 300 of these boards were sent out as part of a now cancelled BeagleBoard.org project. I2C timing data is based on the device tree in the vendor u-boot port. Heartbeat LED added by Geert. Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2021-12-16RISC-V: Add initial StarFive JH7100 device treeEmil Renner Berthing
Add initial device tree for the JH7100 RISC-V SoC by StarFive Ltd. This is a test chip for their upcoming JH7110 SoC. The CPU and cache data is based on the device tree in the vendor u-boot port. Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
2021-12-13exit: Add and use make_task_dead.Eric W. Biederman
There are two big uses of do_exit. The first is it's design use to be the guts of the exit(2) system call. The second use is to terminate a task after something catastrophic has happened like a NULL pointer in kernel code. Add a function make_task_dead that is initialy exactly the same as do_exit to cover the cases where do_exit is called to handle catastrophic failure. In time this can probably be reduced to just a light wrapper around do_task_dead. For now keep it exactly the same so that there will be no behavioral differences introducing this new concept. Replace all of the uses of do_exit that use it for catastraphic task cleanup with make_task_dead to make it clear what the code is doing. As part of this rename rewind_stack_do_exit rewind_stack_and_make_dead. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-12-13efi: Move efifb_setup_from_dmi() prototype from arch headersJavier Martinez Canillas
Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") made the Generic System Framebuffers (sysfb) driver able to be built on non-x86 architectures. But it left the efifb_setup_from_dmi() function prototype declaration in the architecture specific headers. This could lead to the following compiler warning as reported by the kernel test robot: drivers/firmware/efi/sysfb_efi.c:70:6: warning: no previous prototype for function 'efifb_setup_from_dmi' [-Wmissing-prototypes] void efifb_setup_from_dmi(struct screen_info *si, const char *opt) ^ drivers/firmware/efi/sysfb_efi.c:70:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void efifb_setup_from_dmi(struct screen_info *si, const char *opt) Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Reported-by: kernel test robot <lkp@intel.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20211126001333.555514-1-javierm@redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2021-12-13Merge tag 'v5.16-rc5' into locking/core, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2021-12-10Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski
Andrii Nakryiko says: ==================== bpf-next 2021-12-10 v2 We've added 115 non-merge commits during the last 26 day(s) which contain a total of 182 files changed, 5747 insertions(+), 2564 deletions(-). The main changes are: 1) Various samples fixes, from Alexander Lobakin. 2) BPF CO-RE support in kernel and light skeleton, from Alexei Starovoitov. 3) A batch of new unified APIs for libbpf, logging improvements, version querying, etc. Also a batch of old deprecations for old APIs and various bug fixes, in preparation for libbpf 1.0, from Andrii Nakryiko. 4) BPF documentation reorganization and improvements, from Christoph Hellwig and Dave Tucker. 5) Support for declarative initialization of BPF_MAP_TYPE_PROG_ARRAY in libbpf, from Hengqi Chen. 6) Verifier log fixes, from Hou Tao. 7) Runtime-bounded loops support with bpf_loop() helper, from Joanne Koong. 8) Extend branch record capturing to all platforms that support it, from Kajol Jain. 9) Light skeleton codegen improvements, from Kumar Kartikeya Dwivedi. 10) bpftool doc-generating script improvements, from Quentin Monnet. 11) Two libbpf v0.6 bug fixes, from Shuyi Cheng and Vincent Minet. 12) Deprecation warning fix for perf/bpf_counter, from Song Liu. 13) MAX_TAIL_CALL_CNT unification and MIPS build fix for libbpf, from Tiezhu Yang. 14) BTF_KING_TYPE_TAG follow-up fixes, from Yonghong Song. 15) Selftests fixes and improvements, from Ilya Leoshkevich, Jean-Philippe Brucker, Jiri Olsa, Maxim Mikityanskiy, Tirthendu Sarkar, Yucong Sun, and others. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (115 commits) libbpf: Add "bool skipped" to struct bpf_map libbpf: Fix typo in btf__dedup@LIBBPF_0.0.2 definition bpftool: Switch bpf_object__load_xattr() to bpf_object__load() selftests/bpf: Remove the only use of deprecated bpf_object__load_xattr() selftests/bpf: Add test for libbpf's custom log_buf behavior selftests/bpf: Replace all uses of bpf_load_btf() with bpf_btf_load() libbpf: Deprecate bpf_object__load_xattr() libbpf: Add per-program log buffer setter and getter libbpf: Preserve kernel error code and remove kprobe prog type guessing libbpf: Improve logging around BPF program loading libbpf: Allow passing user log setting through bpf_object_open_opts libbpf: Allow passing preallocated log_buf when loading BTF into kernel libbpf: Add OPTS-based bpf_btf_load() API libbpf: Fix bpf_prog_load() log_buf logic for log_level 0 samples/bpf: Remove unneeded variable bpf: Remove redundant assignment to pointer t selftests/bpf: Fix a compilation warning perf/bpf_counter: Use bpf_map_create instead of bpf_create_map samples: bpf: Fix 'unknown warning group' build warning on Clang samples: bpf: Fix xdp_sample_user.o linking with Clang ... ==================== Link: https://lore.kernel.org/r/20211210234746.2100561-1-andrii@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-12-10arch: Make ARCH_STACKWALK independent of STACKTRACEPeter Zijlstra
Make arch_stack_walk() available for ARCH_STACKWALK architectures without it being entangled in STACKTRACE. Link: https://lore.kernel.org/lkml/20211022152104.356586621@infradead.org/ Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> [Mark: rebase, drop unnecessary arm change] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: https://lore.kernel.org/r/20211129142849.3056714-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-09KVM: RISC-V: Use Makefile.kvm for common filesDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20211121125451.9489-6-dwmw2@infradead.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: Rename kvm_vcpu_block() => kvm_vcpu_halt()Sean Christopherson
Rename kvm_vcpu_block() to kvm_vcpu_halt() in preparation for splitting the actual "block" sequences into a separate helper (to be named kvm_vcpu_block()). x86 will use the standalone block-only path to handle non-halt cases where the vCPU is not runnable. Rename block_ns to halt_ns to match the new function name. No functional change intended. Reviewed-by: David Matlack <dmatlack@google.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20211009021236.4122790-14-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: Drop obsolete kvm_arch_vcpu_block_finish()Sean Christopherson
Drop kvm_arch_vcpu_block_finish() now that all arch implementations are nops. No functional change intended. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Matlack <dmatlack@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20211009021236.4122790-10-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>