Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#579 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
github-actions, linux
Ambito
ci-cd, operating-systems, testing

Direzione di ricerca

Inizia esaminando il repository kernelci-riscv collegato e docs/findings-pointer-masking.md, quindi confronta il boot di QEMU, kselftest, config-drift e il workflow GitHub Actions descritti con i percorsi di integrazione disponibili di KernelCI. L’issue è completa quando sono stati concordati il profilo upstream o il percorso di pubblicazione dei risultati, sono state risolte le preoccupazioni relative alla duplicazione e l’ambito di qualsiasi PR upstream o lavoro di registrazione del laboratorio necessario è stato definito chiaramente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
14
Fork
32
Merge medio
15h 40m
PR unite (30g)
5

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di kernelci/kernelci-project

Tutte le issue di kernelci/kernelci-project

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.