Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

RISC-V Development Partners: local QEMU boot + kselftest pipeline seeking the upstream integration path

Abierto
  • ¿Algo no está bien?
#579 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github-actions, linux
Área
ci-cd, operating-systems, testing

Línea de trabajo

Comienza revisando el repositorio kernelci-riscv enlazado y docs/findings-pointer-masking.md; después, compara el arranque de QEMU, kselftest, config-drift y el flujo de trabajo de GitHub Actions descritos con las rutas de integración disponibles de KernelCI. El issue estará completo cuando se haya acordado el perfil upstream o la ruta de publicación de resultados, se hayan resuelto las preocupaciones sobre la duplicación y se haya definido claramente el alcance de cualquier PR upstream o trabajo de registro del laboratorio necesario.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Context

I am an intern at KUBUDS Tech (a RISC-V International member
organization), working on the RISC-V Development Partners SOW:
https://github.com/riscv-admin/dev-partners/issues/49

Repo: https://github.com/xjysiiau/kernelci-riscv

I am working on a localized KernelCI pipeline for RISC-V targets
(x86 host cross-build, QEMU virt -cpu max as the test target, seeded
openKylin image as the boot target, -snapshot so the image is never
modified). Current state:

  • boot test: cross-built kernel (v7.2.0-rc7, riscv defconfig) boots the
    test image to the login prompt; detection is login-prompt/serial based
    with timeout, producing structured result.json;
  • functional tests: cpuinfo (asserts Vector/Hypervisor ISA extensions)
    and an RVV vector_add self-test (vsetvl/vle/vadd/vse, VLEN reported);
  • kselftests: tools/testing/selftests/riscv (hwprobe/vector/sigreturn/mm/abi)
    built on the host and run inside the booted guest (10 binaries:
    9 pass, 1 known XFAIL - see below);
  • config drift detection: 17-option required contract (Vector/virtio/ext4/
    serial/KVM etc.) + full config diff with FAIL/WARN/INFO levels;
  • CI: GitHub Actions - cloud job (drift check + cross-build) plus a
    self-hosted runner (WSL) executing the full closed loop; per-run results
    are archived and a pass-rate trend table is auto-committed to the repo.

Known finding

abi/pointer_masking "constraint" assertions fail on ZPM-capable platforms
(QEMU -cpu max): the test expects PMLEN round-up without
PR_TAGGED_ADDR_ENABLE, while the kernel resets PMLEN to 0 (commit
3033b2b1e3). Tracked as XFAIL; details:
https://github.com/xjysiiau/kernelci-riscv/blob/main/docs/findings-pointer-masking.md
(reporting to linux-riscv as well)

Questions for the KernelCI community

  1. What is the currently recommended path for adding a RISC-V QEMU test
    profile: Maestro config in kci-dev, or first publishing results via
    KCIDB from our own runner?
  2. Is there existing RISC-V QEMU boot/kselftest coverage we should extend
    rather than duplicate?
  3. Is there interest in registering our self-hosted machine as a pull lab
    for these tests?

Status

Phase 1 (pipeline + boot test) done; Phase 2 (Vector functional tests,
kselftests, config drift detection) done except real-hardware
Hypervisor/KVM testing, for which we are looking for lab partners per the
SOW. Aiming for a Phase 3 upstream PR once the configuration format is
settled.

Lenguaje dominante
Python
Estrellas
14
Forks
32
Merge medio
15 h 40 min
PR fusionados (30 d)
5

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de kernelci/kernelci-project

Todos los issues de kernelci/kernelci-project

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.