- 10 Jul, 2024 1 commit
-
-
Xiao Wang authored
As suggested by the B-ext spec, the Zbc (carry-less multiplication) instructions can be used to accelerate CRC calculations. Currently, the crc32 is the most widely used crc function inside kernel, so this patch focuses on the optimization of just the crc32 APIs. Compared with the current table-lookup based optimization, Zbc based optimization can also achieve large stride during CRC calculation loop, meantime, it avoids the memory access latency of the table-lookup based implementation and it reduces memory footprint. If Zbc feature is not supported in a runtime environment, then the table-lookup based implementation would serve as fallback via alternative mechanism. By inspecting the vmlinux built by gcc v12.2.0 with default optimization level (-O2), we can see below instruction count change for each 8-byte stride in the CRC32 loop: rv64: crc32_be (54->31), crc32_le (54->13), __crc32c_le (54->13) rv32: crc32_be (50->32), crc32_le (50->16), __crc32c_le (50->16) The compile target CPU is little endian, extra effort is needed for byte swapping for the crc32_be API, thus, the instruction count change is not as significant as that in the *_le cases. This patch is tested on QEMU VM with the kernel CRC32 selftest for both rv64 and rv32. Running the CRC32 selftest on a real hardware (SpacemiT K1) with Zbc extension shows 65% and 125% performance improvement respectively on crc32_test() and crc32c_test(). Signed-off-by:
Xiao Wang <xiao.w.wang@intel.com> Reviewed-by:
Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20240621054707.1847548-1-xiao.w.wang@intel.comSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
- 26 Jun, 2024 39 commits
-
-
Palmer Dabbelt authored
Björn Töpel <bjorn@kernel.org> says: From: Björn Töpel <bjorn@rivosinc.com> ================================================================ Memory Hot(Un)Plug support (and ZONE_DEVICE) for the RISC-V port ================================================================ Introduction ============ To quote "Documentation/admin-guide/mm/memory-hotplug.rst": "Memory hot(un)plug allows for increasing and decreasing the size of physical memory available to a machine at runtime." This series adds memory hot(un)plugging, and ZONE_DEVICE support for the RISC-V Linux port. MM configuration ================ RISC-V MM has the following configuration: * Memory blocks are 128M, analogous to x86-64. It uses PMD ("hugepage") vmemmaps. From that follows that 2M (PMD) worth of vmemmap spans 32768 pages á 4K which gets us 128M. * The pageblock size is the minimum minimum virtio_mem size, and on RISC-V it's 2M (2^9 * 4K). Implementation ============== The PGD table on RISC-V is shared/copied between for all processes. To avoid doing page table synchronization, the first patch (patch 1) pre-allocated the PGD entries for vmemmap/direct map. By doing that the init_mm PGD will be fixed at kernel init, and synchronization can be avoided all together. The following two patches (patch 2-3) does some preparations, followed by the actual MHP implementation (patch 4-5). Then, MHP and virtio-mem are enabled (patch 6-7), and finally ZONE_DEVICE support is added (patch 8). MHP and locking =============== TL;DR: The MHP does not step on any toes, except for ptdump. Additional locking is required for ptdump. Long version: For v2 I spent some time digging into init_mm synchronization/update. Here are my findings, and I'd love them to be corrected if incorrect. It's been a gnarly path... The `init_mm` structure is a special mm (perhaps not a "real" one). It's a "lazy context" that tracks kernel page table resources, e.g., the kernel page table (swapper_pg_dir), a kernel page_table_lock (more about the usage below), mmap_lock, and such. `init_mm` does not track/contain any VMAs. Having the `init_mm` is convenient, so that the regular kernel page table walk/modify functions can be used. Now, `init_mm` being special means that the locking for kernel page tables are special as well. On RISC-V the PGD (top-level page table structure), similar to x86, is shared (copied) with user processes. If the kernel PGD is modified, it has to be synched to user-mode processes PGDs. This is avoided by pre-populating the PGD, so it'll be fixed from boot. The in-kernel pgd regions are documented in `Documentation/arch/riscv/vm-layout.rst`. The distinct regions are: * vmemmap * vmalloc/ioremap space * direct mapping of all physical memory * kasan * modules, BPF * kernel Memory hotplug is the process of adding/removing memory to/from the kernel. Adding is done in two phases: 1. Add the memory to the kernel 2. Online memory, making it available to the page allocator. Step 1 is partially architecture dependent, and updates the init_mm page table: * Update the direct map page tables. The direct map is a linear map, representing all physical memory: `virt = phys + PAGE_OFFSET` * Add a `struct page` for each added page of memory. Update the vmemmap (virtual mapping to the `struct page`, so we can easily transform a kernel virtual address to a `struct page *` address. From an MHP perspective, there are two regions of the PGD that are updated: * vmemmap * direct mapping of all physical memory The `struct mm_struct` has a couple of locks in play: * `spinlock_t page_table_lock` protects the page table, and some counters * `struct rw_semaphore mmap_lock` protect an mm's VMAs Note again that `init_mm` does not contain any VMAs, but still uses the mmap_lock in some places. The `page_table_lock` was originally used to to protect all pages tables, but more recently a split page table lock has been introduced. The split lock has a per-table lock for the PTE and PMD tables. If split lock is disabled, all tables are guarded by `mm->page_table_lock` (for user processes). Split page table locks are not used for init_mm. MHP operations is typically synchronized using `DEFINE_STATIC_PERCPU_RWSEM(mem_hotplug_lock)`. Actors ------ The following non-MHP actors in the kernel traverses (read), and/or modifies the kernel PGD. * `ptdump` Walks the entire `init_mm`, via `ptdump_walk_pgd()` with the `mmap_write_lock(init_mm)` taken. Observation: ptdump can race with MHP, and needs additional locking to avoid crashes/races. * `set_direct_*` / `arch/riscv/mm/pageattr.c` The `set_direct_*` functionality is used to "synchronize" the direct map to other kernel mappings, e.g. modules/kernel text. The direct map is using "as large huge table mappings as possible", which means that the `set_direct_*` might need to split the direct map. The `set_direct_*` functions operates with the `mmap_write_lock(init_mm)` taken. Observation: `set_direct_*` uses the direct map, but will never modify the same entry as MHP. If there is a mapping, that entry will never race with MHP. Further, MHP acts when memory is offline. * HVO / `mm/hugetlb_vmemmap` HVO optimizes the backing `struct page` for hugetlb pages, which means changing the "vmemmap" region. HVO can split (merge?) a vmemmap pmd. However, it will never race with MHP, since HVO only operates at online memory. HVO cannot touch memory being MHP added or removed. * `apply_to_page_range` Walks a range, creates pages and applies a callback (setting permissions) for the page. When creating a table, it might use `int __pte_alloc_kernel(pmd_t *pmd)` which takes the `init_mm.page_table_lock` to synchronize pmd populate. Used by: `mm/vmalloc.c` and `mm/kasan/shadow.c`. The KASAN callback takes the `init_mm.page_table_lock` to synchronize pte creation. Observations: `apply_to_page_range` applies to the "vmalloc/ioremap space" region, and "kasan" region. *Not* affected by MHP. * `apply_to_existing_page_range` Walks a range, applies a callback (setting permissions) for the page (no page creation). Used by: `kernel/bpf/arena.c` and `mm/kasan/shadow.c`. The KASAN callback takes the `init_mm.page_table_lock` to synchronize pte creation. *Not* affected by MHP regions. * `apply_to_existing_page_range` applies to the "vmalloc/ioremap space" region, and "kasan" region. *Not* affected by MHP regions. * `ioremap_page_range` and `vmap_page_range` Uses the same internal function, and might create table entries at the "vmalloc/ioremap space" region. Can call `__pte_alloc_kernel()` which takes the `init_mm.page_table_lock` synchronizing pmd populate in the region. *Not* affected by MHP regions. Summary: * MHP add will never modify the same page table entries, as any of the other actors. * MHP remove is done when memory is offlined, and will not clash with any of the actors. * Functions that walk the entire kernel page table need synchronization * It's sufficient to add the MHP lock ptdump. Testing ======= This series adds basic DT supported hotplugging. There is a QEMU series enabling MHP for the RISC-V "virt" machine here: [1] ACPI/MSI support is still in the making for RISC-V, and prior proper (ACPI) PCI MSI support lands [2] and NUMA SRAT support [3], it hard to try it out. I've prepared a QEMU branch with proper ACPI GED/PC-DIMM support [4], and a this series with the required prerequisites [5] (AIA, ACPI AIA MADT, ACPI NUMA SRAT). To test with virtio-mem, e.g.: | qemu-system-riscv64 \ | -machine virt,aia=aplic-imsic \ | -cpu rv64,v=true,vlen=256,elen=64,h=true,zbkb=on,zbkc=on,zbkx=on,zkr=on,zkt=on,svinval=on,svnapot=on,svpbmt=on \ | -nodefaults \ | -nographic -smp 8 -kernel rv64-u-boot.bin \ | -drive file=rootfs.img,format=raw,if=virtio \ | -device virtio-rng-pci \ | -m 16G,slots=3,maxmem=32G \ | -object memory-backend-ram,id=mem0,size=16G \ | -numa node,nodeid=0,memdev=mem0 \ | -serial chardev:char0 \ | -mon chardev=char0,mode=readline \ | -chardev stdio,mux=on,id=char0 \ | -device pci-serial,id=serial0,chardev=char0 \ | -object memory-backend-ram,id=vmem0,size=2G \ | -device virtio-mem-pci,id=vm0,memdev=vmem0,node=0 where "rv64-u-boot.bin" is U-boot with EFI/ACPI-support (use [6] if you're lazy). In the QEMU monitor: | (qemu) info memory-devices | (qemu) qom-set vm0 requested-size 1G ...to test DAX/KMEM, use the follow QEMU parameters: | -object memory-backend-file,id=mem1,share=on,mem-path=virtio_pmem.img,size=4G \ | -device virtio-pmem-pci,memdev=mem1,id=nv1 and the regular ndctl/daxctl dance. If you're brave to try the ACPI branch, add "acpi=on" to "-machine virt", and test PC-DIMM MHP (in addition to virtio-{p},mem): In the QEMU monitor: | (qemu) object_add memory-backend-ram,id=mem1,size=1G | (qemu) device_add pc-dimm,id=dimm1,memdev=mem1 You can also try hot-remove with some QEMU options, say: | -object memory-backend-file,id=mem-1,size=256M,mem-path=/pagesize-2MB | -device pc-dimm,id=mem1,memdev=mem-1 | -object memory-backend-file,id=mem-2,size=1G,mem-path=/pagesize-1GB | -device pc-dimm,id=mem2,memdev=mem-2 | -object memory-backend-file,id=mem-3,size=256M,mem-path=/pagesize-2MB | -device pc-dimm,id=mem3,memdev=mem-3 Remove "acpi=on" to run with DT. Thanks to Alex, Andrew, David, and Oscar for all comments/tests/fixups. References ========== [1] https://lore.kernel.org/qemu-devel/20240521105635.795211-1-bjorn@kernel.org/ [2] https://lore.kernel.org/linux-riscv/20240501121742.1215792-1-sunilvl@ventanamicro.com/ [3] https://lore.kernel.org/linux-riscv/cover.1713778236.git.haibo1.xu@intel.com/ [4] https://github.com/bjoto/qemu/commits/virtio-mem-pc-dimm-mhp-acpi-v2/ [5] https://github.com/bjoto/linux/commits/mhp-v4-acpi [6] https://github.com/bjoto/riscv-rootfs-utils/tree/acpi * b4-shazam-merge: riscv: Enable DAX VMEMMAP optimization riscv: mm: Add support for ZONE_DEVICE virtio-mem: Enable virtio-mem for RISC-V riscv: Enable memory hotplugging for RISC-V riscv: mm: Take memory hotplug read-lock during kernel page table dump riscv: mm: Add memory hotplugging support riscv: mm: Add pfn_to_kaddr() implementation riscv: mm: Refactor create_linear_mapping_range() for memory hot add riscv: mm: Change attribute from __init to __meminit for page functions riscv: mm: Pre-allocate vmemmap/direct map/kasan PGD entries riscv: mm: Properly forward vmemmap_populate() altmap parameter Link: https://lore.kernel.org/r/20240605114100.315918-1-bjorn@kernel.orgSigned-off-by: -
Björn Töpel authored
Now that DAX is usable, enable the DAX VMEMMAP optimization as well. Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Reviewed-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20240605114100.315918-12-bjorn@kernel.orgSigned-off-by:
-
Björn Töpel authored
ZONE_DEVICE pages need DEVMAP PTEs support to function (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit in the PTE for DEVMAP mark, add the corresponding helpers, and enable ARCH_HAS_PTE_DEVMAP for riscv64. Reviewed-by:
-
Björn Töpel authored
Now that RISC-V has memory hotplugging support, virtio-mem can be used on the platform. Acked-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
-
Björn Töpel authored
Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for RISC-V. Reviewed-by:
-
Björn Töpel authored
During memory hot remove, the ptdump functionality can end up touching stale data. Avoid any potential crashes (or worse), by holding the memory hotplug read-lock while traversing the page table. This change is analogous to arm64's commit bf2b59f6 ("arm64/mm: Hold memory hotplug lock while walking for kernel page table dump"). Reviewed-by:
Oscar Salvador <osalvador@suse.de> Signed-off-by:
-
Björn Töpel authored
For an architecture to support memory hotplugging, a couple of callbacks needs to be implemented: arch_add_memory() This callback is responsible for adding the physical memory into the direct map, and call into the memory hotplugging generic code via __add_pages() that adds the corresponding struct page entries, and updates the vmemmap mapping. arch_remove_memory() This is the inverse of the callback above. vmemmap_free() This function tears down the vmemmap mappings (if CONFIG_SPARSEMEM_VMEMMAP is enabled), and also deallocates the backing vmemmap pages. Note that for persistent memory, an alternative allocator for the backing pages can be used; The vmem_altmap. This means that when the backing pages are cleared, extra care is needed so that the correct deallocation method is used. arch_get_mappable_range() This functions returns the PA range that the direct map can map. Used by the MHP internals for sanity checks. The page table unmap/teardown functions are heavily based on code from the x86 tree. The same remove_pgd_mapping() function is used in both vmemmap_free() and arch_remove_memory(), but in the latter function the backing pages are not removed. Signed-off-by:
-
Björn Töpel authored
The pfn_to_kaddr() function is used by KASAN's memory hotplugging path. Add the missing function to the RISC-V port, so that it can be built with MHP and CONFIG_KASAN. Signed-off-by:
-
Björn Töpel authored
Add a parameter to the direct map setup function, so it can be used in arch_add_memory() later. Reviewed-by:
-
Björn Töpel authored
Prepare for memory hotplugging support by changing from __init to __meminit for the page table functions that are used by the upcoming architecture specific callbacks. Changing the __init attribute to __meminit, avoids that the functions are removed after init. The __meminit attribute makes sure the functions are kept in the kernel text post init, but only if memory hotplugging is enabled for the build. Reviewed-by:
-
Björn Töpel authored
The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to all userland page tables, which means that if the PGD level table is changed, other page tables has to be updated as well. Instead of having the PGD changes ripple out to all tables, the synchronization can be avoided by pre-allocating the PGD entries/pages at boot, avoiding the synchronization all together. This is currently done for the bpf/modules, and vmalloc PGD regions. Extend this scheme for the PGD regions touched by memory hotplugging. Prepare the RISC-V port for memory hotplug by pre-allocate vmemmap/direct map/kasan entries at the PGD level. This will roughly waste ~128 (plus 32 if KASAN is enabled) worth of 4K pages when memory hotplugging is enabled in the kernel configuration. Reviewed-by:
-
Björn Töpel authored
Make sure that the altmap parameter is properly passed on to vmemmap_populate_hugepages(). Reviewed-by:
-
Haibo Xu authored
Enable the dmi driver for riscv which would allow access the SMBIOS info through some userspace file(/sys/firmware/dmi/*). The change was based on that of arm64 and has been verified by dmidecode tool. Signed-off-by:
Haibo Xu <haibo1.xu@intel.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20240613065507.287577-1-haibo1.xu@intel.comSigned-off-by:
-
Alexandre Ghiti authored
Like other architectures, a pte is accessible if it is present or if there is a pending tlb flush and the pte is protnone (which could be the case when a pte is downgraded to protnone before a flush tlb is executed). Signed-off-by:
-
Palmer Dabbelt authored
Clément Léger <cleger@rivosinc.com> says: Add support for (yet again) more RVA23U64 missing extensions. Add support for Zimop, Zcmop, Zca, Zcf, Zcd and Zcb extensions ISA string parsing, hwprobe and kvm support. Zce, Zcmt and Zcmp extensions have been left out since they target microcontrollers/embedded CPUs and are not needed by RVA23U64. Since Zc* extensions states that C implies Zca, Zcf (if F and RV32), Zcd (if D), this series modifies the way ISA string is parsed and now does it in two phases. First one parses the string and the second one validates it for the final ISA description. * b4-shazam-merge: KVM: riscv: selftests: Add Zcmop extension to get-reg-list test RISC-V: KVM: Allow Zcmop extension for Guest/VM riscv: hwprobe: export Zcmop ISA extension riscv: add ISA extension parsing for Zcmop dt-bindings: riscv: add Zcmop ISA extension description KVM: riscv: selftests: Add some Zc* extensions to get-reg-list test RISC-V: KVM: Allow Zca, Zcf, Zcd and Zcb extensions for Guest/VM riscv: hwprobe: export Zca, Zcf, Zcd and Zcb ISA extensions riscv: add ISA parsing for Zca, Zcf, Zcd and Zcb riscv: add ISA extensions validation callback dt-bindings: riscv: add Zca, Zcf, Zcd and Zcb ISA extension description KVM: riscv: selftests: Add Zimop extension to get-reg-list test RISC-V: KVM: Allow Zimop extension for Guest/VM riscv: hwprobe: export Zimop ISA extension riscv: add ISA extension parsing for Zimop dt-bindings: riscv: add Zimop ISA extension description Link: https://lore.kernel.org/r/20240619113529.676940-1-cleger@rivosinc.comSigned-off-by:
-
Clément Léger authored
The KVM RISC-V allows Zcmop extension for Guest/VM so add this extension to get-reg-list test. Signed-off-by:
Clément Léger <cleger@rivosinc.com> Reviewed-by:
Anup Patel <anup@brainfault.org> Acked-by:
-
Clément Léger authored
Extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zcmop extension for Guest/VM. Signed-off-by:
-
Clément Léger authored
Export Zcmop ISA extension through hwprobe. Signed-off-by:
Evan Green <evan@rivosinc.com> Link: https://lore.kernel.org/r/20240619113529.676940-15-cleger@rivosinc.comSigned-off-by:
-
Clément Léger authored
Add parsing for Zcmop ISA extension which was ratified in commit c732a4f39a4c ("Zcmop is ratified/1.0") of the riscv-isa-manual. Signed-off-by:Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Clément Léger authored
Add description for the Zcmop (Compressed May-Be-Operations) ISA extension which was ratified in commit c732a4f39a4c ("Zcmop is ratified/1.0") of the riscv-isa-manual. Signed-off-by: -
Clément Léger authored
The KVM RISC-V allows Zca, Zcf, Zcd and Zcb extensions for Guest/VM so add these extensions to get-reg-list test. Signed-off-by:
-
Clément Léger authored
Extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zca, Zcf, Zcd and Zcb extensions for Guest/VM. Signed-off-by:
-
Clément Léger authored
Export Zca, Zcf, Zcd and Zcb ISA extension through hwprobe. Signed-off-by:
-
Clément Léger authored
The Zc* standard extension for code reduction introduces new extensions. This patch adds support for Zca, Zcf, Zcd and Zcb. Zce, Zcmt and Zcmp are left out of this patch since they are targeting microcontrollers/ embedded CPUs instead of application processors. Signed-off-by:
-
Clément Léger authored
Since a few extensions (Zicbom/Zicboz) already needs validation and future ones will need it as well (Zc*) add a validate() callback to struct riscv_isa_ext_data. This require to rework the way extensions are parsed and split it in two phases. First phase is isa string or isa extension list parsing and consists in enabling all the extensions in a temporary bitmask (source isa) without any validation. The second step "resolves" the final isa bitmap, handling potential missing dependencies. The mechanism is quite simple and simply validate each extension described in the source bitmap before enabling it in the resolved isa bitmap. validate() callbacks can return either 0 for success, -EPROBEDEFER if extension needs to be validated again at next loop. A previous ISA bitmap is kept to avoid looping multiple times if an extension dependencies are never satisfied until we reach a stable state. In order to avoid any potential infinite looping, allow looping a maximum of the number of extension we handle. Zicboz and Zicbom extensions are modified to use this validation mechanism. Signed-off-by:
-
Clément Léger authored
Add description for Zca, Zcf, Zcd and Zcb extensions which are part the Zc* standard extensions for code size reduction. Additional validation rules are added since Zcb depends on Zca, Zcf, depends on Zca and F, Zcd depends on Zca and D and finally, Zcf can not be present on rv64. Signed-off-by:
-
Clément Léger authored
The KVM RISC-V allows Zimop extension for Guest/VM so add this extension to get-reg-list test. Signed-off-by:
-
Clément Léger authored
Extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zimop extension for Guest/VM. Signed-off-by:
-
Clément Léger authored
Export Zimop ISA extension through hwprobe. Signed-off-by:
-
Clément Léger authored
Add parsing for Zimop ISA extension which was ratified in commit 58220614a5f of the riscv-isa-manual. Signed-off-by:
-
Clément Léger authored
Add description for the Zimop (May-Be-Operations) ISA extension which was ratified in commit 58220614a5f of the riscv-isa-manual. Signed-off-by:
-
Palmer Dabbelt authored
Samuel Holland <samuel.holland@sifive.com> says: Here are a few changes to minimize calls to stop_machine() and flush_icache_*() in the various text patching functions, as well as to simplify the code. * b4-shazam-merge: riscv: Remove extra variable in patch_text_nosync() riscv: Use offset_in_page() in text patching functions riscv: Pass patch_text() the length in bytes riscv: Simplify text patching loops riscv: kprobes: Use patch_text_nosync() for insn slots riscv: jump_label: Simplify assembly syntax riscv: jump_label: Batch icache maintenance Link: https://lore.kernel.org/r/20240327160520.791322-1-samuel.holland@sifive.comSigned-off-by:
-
Samuel Holland authored
This cast is superfluous, and is incorrect anyway if compressed instructions may be present. Reviewed-by:
Samuel Holland <samuel.holland@sifive.com> Reviewed-by:
-
Samuel Holland authored
This is a bit easier to parse than the equivalent bit manipulation. Reviewed-by:
-
Samuel Holland authored
patch_text_nosync() already handles an arbitrary length of code, so this removes a superfluous loop and reduces the number of icache flushes. Reviewed-by:
-
Samuel Holland authored
This reduces the number of variables and makes the code easier to parse. Signed-off-by:
-
Samuel Holland authored
These instructions are not yet visible to the rest of the system, so there is no need to do the whole stop_machine() dance. Reviewed-by:
-
Samuel Holland authored
The idiomatic way to write "jal zero" is "j". Reviewed-by:
-
Samuel Holland authored
Switch to the batched version of the jump label update functions so instruction cache maintenance is deferred until the end of the update. Reviewed-by:
-
