From: Richard W.M. Jones Date: Tue, 4 Jun 2024 15:01:34 +0000 (+0100) Subject: The main talk is a google presentation X-Git-Url: http://git.annexia.org/?a=commitdiff_plain;h=13cf8f0a842ff19c2e1890c8da651adb682920d8;p=riscv-talks.git The main talk is a google presentation This directory just contains assets and the talk background. --- diff --git a/2024-devconf/2024-riscv64-devconf-outline.txt b/2024-devconf/2024-riscv64-devconf-outline.txt new file mode 100644 index 0000000..6cfb81d --- /dev/null +++ b/2024-devconf/2024-riscv64-devconf-outline.txt @@ -0,0 +1,220 @@ +So this is my outline plan, including the things we discussed on IRC +yesterday ... + +> > https://pretalx.com/devconf-cz-2024/talk/Q7XB3M/ + +> * One slide timeline of the project, showing start and major +> milestones. Just show, don't talk about it. + +[David] + +> Talk is fine, but it's too easy to overspend time here. Probably: +> - When we started, and re-started (after glibc ABI stabilization). +> - All historical (archival bits are available) from day 1. +> - Koji setup (libvirt up to 180 VMs in GCC Compiler Farm). +> - New Koji setup with SiFive HiFive Unmatched boards (thanks SiFive and WDC +> mainly). +> - Boards hosted by the community (not many). +> - Now Koji is in AWS, Fedora infra  managed resources (well, one VM). +> - Pioneer connected (thanks RVI). +> - VF2 is pending to be connected after new disk images are prepared (thanks +> StarFive). + +Personally I'd just sum this up in a diagram on one slide, and not +even talk about it. Something like: + + --- 2016 project starts + | + | + --- 2018 HiFive Unleashed + | + | + etc + | + --- 2024 Fedora 41 + +> * Current status - Fedora 40 & Fedora 41 status.  What boards are +>   supported and/or recommended. + +[David] + +> Unmatched what Fedora mainly uses (same with Debian too). +> VF2 is about to enter the game basically. +> I would expect ESWIN/SiFive P550 boards to quickly join a list. +> +> * Commercial interest in RISC-V.  The current companies developing +>   RISC-V hardware (as far as we can reveal).  Might stick to server +>   hardware, since talking about _all_ the companies doing RISC-V could +>   be impossible. + +[David] + +> SiFive, T-HEAD, Rivos, Ventana, Tenstorrent? +> Well these are the validated or kinda trusted folks. SupermiT claims server +> stuff with their X100, but a lot is unknown. + + +> * RVI and RISE. + +[Richard] + +Slide: RISC-V International (RVI) + +https://riscv.org/ + +Slide: Members page + +https://riscv.org/members/ + +Red Hat is a member of RVI through our parent company, IBM. +Fedora is not directly a member. + +Slide: RISC-V groups + +https://tech.riscv.org/groups + +The range of things that RVI does is enormous, but to summarise +this, it's steering the hardware and ISA standards and general +collaboration. + +Slide: RISE + +https://riseproject.dev/ + +Red Hat is directly a member. We contribute 2 full time engineer +equivalent people to the project. + +Slide: RISE TSCs + +(lower down same page) + +RISE tends to concentrate more at the software level, filling in +gaps in the software and working with Linux distributions. + + + + +> Yes. One is handling open source standards, and collaboration in +> general. Another one is to fill the gaps in the software and avoid +> duplicated expensive development. We should show an up-to-date list +> of the companies in RISE. It has grown: +> https://wiki.riseproject.dev/display/HOME/About+RISE + + +> * Profiles.  Tension between supporting future hardware and what is +>   currently available for developers. + +[Richard] + +Slide: Profiles SIG + +https://jira.riscv.org/browse/RVG-156?src=confmacro +or https://lists.riscv.org/g/sig-profiles + +I don't want to go deeply into RISC-V and extensions. I wrote +an article about this recently for Red Hat Research Quarterly if +you're interested in finding out more. + +Slide: RVA23 + +But an important effort in RISC-V is grouping certain hardware +features into mandatory and optional layers which are called +"profiles". + +The mandatory part of the standard includes: + + - vector extension + - hypervisor extension + - hardware performance counters + - cache coherence + - "maybe" operations + - page-based memory types + - fine-grained TLB invalidation + - 39-bit virtual memory + +Optional extensions include: + + - vector crypto + - byte, halfword atomic ops + - FP16 + - 48- and 57-bit virtual memory + - raising exception on unimplemented opcodes (controversial!) + +Slide: RVA24 + +Under discussion! + +New naming scheme. + +> Yes. +> This is a complicated topic, and I am not fully up to date. +> RVA 23/24, minor/major. +> New naming scheme being discussed? +> Note that deprecating extensions is kinda fine. We should talk about this being +> a possibility. +> +> You are more likely up to date with this. + + +> * CentOS Stream 10 work.  The path from Fedora 40 -> CS10.  How +>   changes have to go upstream first. + +[Richard] + +Slide: Diagram showing downstream -> upstream -> F40 -> CS10 relationships + Students in China, David, etc. + +> Yes. +> We basically want this ASAP, but we have done very minimal effort so far. +> +> * New Koji hub instance, integration with FAS so any Fedora packager +>   can build. + +[Richard, input from Kevin] + +Slide: Screenshot of current Koji + +We're building a new Koji hub. + +Not the same as Fedora Koji (yet). + +Will be accessible by any Fedora packager, but might need pre-approval. + +Will automatically rebuild most Fedora packages, but doesn't block them. + +> Yes. +> I don't think we have all the answers here, but maybe Kevin does. +> TLDR; We will have a new Koji (still separate), but much closer to the existing +> setup with FAS integration, and some form of koji-shadow. +> +> +> * Future plans for RISC-V as a primary architecture. + +[Richard] + +Slide: RISC-V as a primary Fedora architecture + +This is our long term goal. + +We're possibly talking about Fedora 42, but nothing has been decided. + +It requires better hardware to be available, especially higher end +development boards and maybe server hardware. + + + + +> Yes. +> Nothing to hide, we are going for the 1st tier (primary) architecture support. +> It's mainly blocked by proper server hardware availability. +> Some things we should mention: +> - Symlink hack we had, and that some folks will not like it. +> - Potential of a new ABI if things move towards that direction. + +Rich. + +-- +Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones +Read my programming and virtualization blog: http://rwmj.wordpress.com +libguestfs lets you edit virtual machines. Supports shell scripting, +bindings from many languages. http://libguestfs.org diff --git "a/2024-devconf/Screenshot 2024-06-04 at 15-59-04 RISC-V International \342\200\223 RISC-V The Open Standard RISC Instruction Set Architecture.png" "b/2024-devconf/Screenshot 2024-06-04 at 15-59-04 RISC-V International \342\200\223 RISC-V The Open Standard RISC Instruction Set Architecture.png" new file mode 100644 index 0000000..48dd89f Binary files /dev/null and "b/2024-devconf/Screenshot 2024-06-04 at 15-59-04 RISC-V International \342\200\223 RISC-V The Open Standard RISC Instruction Set Architecture.png" differ diff --git "a/2024-devconf/Screenshot 2024-06-04 at 15-59-45 Members \342\200\223 RISC-V International.png" "b/2024-devconf/Screenshot 2024-06-04 at 15-59-45 Members \342\200\223 RISC-V International.png" new file mode 100644 index 0000000..83de54f Binary files /dev/null and "b/2024-devconf/Screenshot 2024-06-04 at 15-59-45 Members \342\200\223 RISC-V International.png" differ