This document lists the current 2H23 priorities as of 8/23/2023.
Contents:
| Table of Contents |
|---|
Work Group-Identified Priorities
Developer Infrastructure
This is a new WG that currently oversees the Build Farm project.
System Libraries
Lead is Nathan Egge (Google).
...
- SL_00_001 - bionic
- SL_00_002 - glibc
- (blocked) SL_00_003 - OpenSSL
- (blocked) SL_00_004 - BoringSSL
- SL_00_005 - zlib-ng
- SL_01_001 - libflac
- SL_02_001 - OpenBLAS
- SL_0203_002 001 - XNNPACK
This WG has 3 distinct subcategories:
...
- LK_01_032 - Vector extension discovery using HWPROBE
- LK_01_005 - Native/hosted debug support (aka HW breakpoint)
- LK_01_020 - Vector crypto extensions supportdiscovery using HWPROBE
- SE_02_001 - QEMU Vector crypto support
...
Current focus is on Qemu improvements to improve overall developer experience around Qemu, including feature completeness in modeling the emulated userspace Linux environment, improvements to host support for certain platform features and improvements to the emulated platforms to sustain new use-cases.
No projects are requesting RISE resources at this timeA number of projects are already completed and upstreamed, and these are consequently crossed out.
SE_01_001 - QEMU linux-user riscv_hwprobe syscall support- (upstreaming) SE_01_002 - QEMU Virtual IRQ and IRQ filtering support
- SE_01_003 - QEMU WorldGuard support
- SE_01_004 - QEMU IOPMP support
- SE_01_005 - QEMU PCIe passthru on x86 hosts
- (upstreaming) SE_01_009 - QEMU ACPI support for AIA
- (upstreaming) SE_01_010 - QEMU ACPI support for PLIC
- SE_01_011 - QEMU RVA22U64/S64 profile RVA22 profiles support
SE_02_001 - QEMU Vector crypto support
No projects are requesting RISE resources at this time.
Language Runtimes
Lead is Ludovic Henry (Rivos).
- LR_00_004: Backport RISC-V support to jdk11u
- LR_00_005: Backport RISC-V support to jdk17u
- LR_00_007: Distribute Java 11 + 17 + 21 in Adoptium
- LR_01_002: Port Numpy (for PyTorch and SciKit-Learn)
- LR_02_001: Build and test Go Runtime on RISC-V
- LR_04_001: Port .NET Runtime to RISC-V
- LR_05_001: Improve support of ART on RISC-V
...
- Kernel
- LK_00_005 - Memory Hot(Un)plug
LK_00_006 - KASAN supportLK_01_001 - Basic ACPI support- (upstreaming) LK_01_002 - ACPI support for PLIC driver
- (upstreaming) LK_01_003 - AIA drivers with DT support
- (upstreaming) LK_01_004 - ACPI support for AIA drivers
- (upstreaming) LK_01_005 - Native/hosted debug support (aka HW breakpoint)
LK_01_006 - Vector extension support- (upstreaming) LK_01_007 - IOMMU driver with DT support
- (upstreaming) LK_01_020 - Vector crypto extensions supportdiscovery using HWPROBE
- LK_01_032 - Vector extension discovery using HWPROBE
- (upstreaming) LK_01_033 - Bitmanip extension discovery using HWPROBE
- KVM
LK_02_002 - KVM AIA in-kernel irqchip- (upstreaming) LK_02_003 - KVM AIA IMSIC guest file support
- LK_02_004 - KVM AIA irq-bypass (aka Device MSI virtualization)
LK_02_005 - KVM vector extension virtualization- LK_02_011 - KVM Native/hosted debug virtualization
LK_02_018 - KVM bitmanip extension virtualization- LK_02_019 - KVM vector crypto extension virtualization
- (upstreaming) LK_03_002 - KVMTOOL AIA in-kernel irqchip
- LK_03_004 - KVMTOOL VFIO + irq-bypass support
LK_03_007 - QEMU-KVM AIA in-kernel irqchip- LK_03_010 - QEMU-KVM VFIO + irq-bypass support
- LK_03_016 - KVMTOOL vector crypto support
- LK_03_017 - KVMTOOL bitmanip support
- LK_03_018 - QEMU-KVM vector crypto support
- LK_03_019 - QEMU-KVM bitmanip support
...
Currently prioritized projects primarily revolve around Tiano EDK2 enablement - core support to support new hardware (SSTC, CMO, MMU), platform support projects (StandaloneMmPkg for secure flash, MultiArchUefiPkg for PCIe OpRom emulation). Some work is already completed and is either going through upstreaming (CMO, MMU support) or further community validation (MultiArchUefiPkg). Two of the projects are net new contributions - StandaloneMmPkg port to RISC-V and TF-M port to RISC-V.
No projects are requesting RISE resources at this time.
The CoVE and CoVE-IO specs need to evolve to accommodate StandaloneMmPkg scenario.
- Tianocore EDK2 UEFI
- TF-M
There's been an interest in porting TF-A, but this has not yet solidified into something concrete.
No projects are requesting RISE resources at this time.
Distro Integration
Lead is Brian Harrington (Red Hat).
...
...
- CT_01_006 - Large Code Model (LLVM)
- CT_01_005 - Fusion Support (LLVM)
CT_01_004 -- Zfa Support (LLVM)- CT_01_003 - Shadow Stacks (LLVM)
CT_01_002 - Forward Compatible Atomic Mappings (LLVM)- CT_01_001 - Autovectorization -- Basic Functionality (LLVM)
GCC Enablement
- CT_00_009 - Large Code Model (GCC)
- CT_00_008 - Backtracing support without using external tables (GCC)
- (upstreaming) CT_00_007 - Fusion Support (GCC)
- (upstreaming) CT_00_006 -- Zfa Support (GCC)
- CT_00_005 -- Zicond with if-conversion improvements (GCC)
- CT_00_004 -- Address rewriting (GCC)
CT_00_003 -- Redundant Extension Elimination (GCC)CT_00_002 - Inline Subword Atomics and , Forward Compatible Mappings, Ztso (GCC)- CT_00_001 - Autovectorization -- Basic Functionality (GCC)
Distribution
...
Specification Dependencies
- RVI CoVE: for EDK2_00_02 - StandaloneMmPkg (PoC)
- RVI CoVE-IO: for EDK2_00_02 - StandaloneMmPkg (PoC)
- UEFI PI: EDK2_00_02 - StandaloneMmPkg (PoC)
- RVI SBI Debug Trigger Extension: LK_01_005 - Native/hosted debug support (aka HW breakpoint)
- RVI RISC-V Cryptography Extensions: SL_00_003 - OpenSSL
- RVI psABI vector ABI: CT_03_001 - Binary Toolchain Packages
- RVI psABI: CT_01_003 - Shadow Stacks (LLVM)
- RVI psABI: CT_00_009 - Large Code Model (GCC) (https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/388)
- RVI Unified Discovery: Profile- and Extension- Optimized Distros
Observations
Prioritization Activities
Current prioritization efforts were "bottom up". This meant the WGs were largely left to their own devices in terms of identifying priorities. Such an approach enabled the TSC to identify trends to help shape further (1H24, 2H24) priorities.
Overall, three trends (market directions) are evident:
- General-purpose compute (aka "server")
- HPC (differentiated from "server" by a different software stack)
- Consumer / Mobile (Android, Tizen, possible bridges to existing AArch64 software)
These are all dependent on:
- Base developer / SW ecosystem enablement, seen with toolchain/runtime and emulator work.
It's reasonable to work across a couple of directions that are different enough from each other to have the maximum impact from enablement activities. Such two directions could be server and consumer.
Prioritized Projects
...