FuSa SIG/Status: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Scope Definition =
= Scope Definition =
* Hardware
* Hardware
⚫
** Platform core components (no platform drivers): timer, mmu, iommu, irq controller
** Only platform core code (no driver)
⚫
*** timer, mmu, irq controller
** board/platform specific code to be done by user of Xen at this stage
** PCI passthrough out of scope (for now)


* System configuration
* System configuration
** dom0less
** Dom0less
** Mixed criticality (a certifiable VM and a non-certifiable VM)
** Mixed criticality: a certifiable VM and a non-certifiable VM


= Ongoing Efforts =
= Ongoing Efforts =


* Requirements format (doxygen)
* Requirements and documentation
** Doxygen for documentation of internal and external interfaces
** table of requirements followed/to be followed/not applicable
** doorstop (links requirements to code)
** Doorstop to link documentation and requirements to code
** Zephyr solution (originally by Intel) based on doxygen
** Zephyr solution (originally by Intel) based on Doxygen
** In Progress: conversion of hypercalls docs to Doxygen format
A bunch of work was done but more work is required. Request to change all the existing docs into doxygen.
Issue is we only have 1 release cycle to switch to doxygen.
What is the agreement / process to make progress on this? We don't want an 80 patches patch series.
ACTION: bring the topic of the *process* up with the REST


* MISRA C
* Unclear coding style
** MISRA C Working Group established
Can we use an already written coding style? E.g. Zephyr / FreeBSD / Linux / QEMU. Comes with checkpatch.pl.
** MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style.
It needs to have a checker.
** [https://gitlab.com/xen-project/xen/-/blob/staging/docs/misra/rules.rst|MISRA C rules officially accepted in Xen]
It should be a well done well maintained project and coding style.
** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*
Can we find a coding style similar to Xen coding style?
** In Progress: violations reduction and MISRA C rules acceptance
It should work with standard editors.
Can we agree on 2-3 parameters we can use to evaluate coding style?
Are there FuSa friendly factors to consider?
ACTION: bring up adoption of existing coding style


* Static System Definition
* Misra requirement classification
⚫
** Static memory allocation
Marketing. Why the standards are there and why they can be useful. Code quality, testability, security.
⚫
** Static heap allocation
Agree on process: step by step starting from the non-controversial.
⚫
** Static cpupools
ACTION: prepare a webminar 1-2 months (option to use LF webinar)
** Done: cpupools
ACTION: write emails status updates once a quarter
** In Progress: memory and heap allocation
ACTION: keynote at XenSummit


⚫
* Determinism and interference reduction
* First status update:
⚫
** Interrupt latency analysis in Xen
Misra rules already covered
** Cache Coloring
cppcheck that we want to add to Xen
** In Progress: Cache Coloring upstreaming
how much is already covered, burn down on what we want to do
publish real-time capabilities analysis


* Traceability
* Define actionable work packages for any contributors and maintainers
** Trace review comments and patch versions all the way to a commit
** Status: script prototype available to retrieve all mailing list discussions from a commit id


* static code analysis (cppcheck, Coverity, Eclair)
** goal: Misra code compliance

⚫
* Real-time and interference reduction
⚫
** real time analysis of Xen
*** interrupt forward response time
** cache coloring

* commit review tracing
** get info from mailing list archive

* static system definition
⚫
** static memory allocation
⚫
** static heap allocation
⚫
** cpupools


[[Category:Safety Certification/FuSa SIG]]
[[Category:Safety Certification/FuSa SIG]]

Latest revision as of 22:21, 11 August 2022

Scope Definition

  • Hardware
    • Platform core components (no platform drivers): timer, mmu, iommu, irq controller
  • System configuration
    • Dom0less
    • Mixed criticality: a certifiable VM and a non-certifiable VM

Ongoing Efforts

  • Requirements and documentation
    • Doxygen for documentation of internal and external interfaces
    • Doorstop to link documentation and requirements to code
    • Zephyr solution (originally by Intel) based on Doxygen
    • In Progress: conversion of hypercalls docs to Doxygen format
  • MISRA C
    • MISRA C Working Group established
    • MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style.
    • C rules officially accepted in Xen
    • cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*
    • In Progress: violations reduction and MISRA C rules acceptance
  • Static System Definition
    • Static memory allocation
    • Static heap allocation
    • Static cpupools
    • Done: cpupools
    • In Progress: memory and heap allocation
  • Determinism and interference reduction
    • Interrupt latency analysis in Xen
    • Cache Coloring
    • In Progress: Cache Coloring upstreaming
  • Traceability
    • Trace review comments and patch versions all the way to a commit
    • Status: script prototype available to retrieve all mailing list discussions from a commit id
Retrieved from "https://wiki.xenproject.org/index.php?title=FuSa_SIG/Status&oldid=19974"