Difference between revisions of "FuSa SIG/Status"

From Xen
(Ongoing Efforts)
 
(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