FuSa SIG/Roadmap: Difference between revisions

From Xen
Jump to navigationJump to search
(Created page with "= Short term Roadmap and ongoing activities = * Misra compliance ** ongoing: ** Coverity regular analysis (arm) *** CI internal checks ** cppcheck i...")
 
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Short term Roadmap and ongoing activities =
= Short term Roadmap and ongoing activities =
* Misra compliance
* Misra compliance
** ongoing:
** Done:
** Coverity regular analysis (arm)
*** Coverity regular analysis (arm)
*** CI internal checks
*** CI internal checks
** cppcheck integration in Xen (arm)
*** Eclair scanning (Bugseng)
*** cppcheck is buggy, could use clang? or a gcc sanitizer ?
*** MISRA rules in xen.git (partial) with their status
** classify the rules we want to support
*** MISRA fixes violations
** to do:
*** Coding style
⚫
** Ongoing:
⚫
*** create list of rules and put a file in xen.git
**** mention the status of each rule on the list
*** MISRA fixes (or reasoning) for few rules
* Requirements and Assumption of use
*** list the rules already covered by current coding style
** Done:
*** updating the coding style
*** Created and defined a hierarchy of requirements (Market, Product and Design)
*** regular checks on gitlab
*** Generic Timer
⚫
*** classify the rules in order of priority
*** fix the Misra-C issues
*** Emulated UART
*** Traceability using OpenFastTrace
*** mention the Misra rule fixed when fixing findings
** for the future
** Ongoing:
*** submitted patch checks
*** Dom0less domain creation
*** Device passthrough
*** P2M
** To do:
*** GICv3, SMMUv3, vGICv3, hyper calls, IOMMU, LAPIC, hypercalls
⚫
*** a way to trigger updating the rules in case of code changes
* Architecture specifications
** Done:
*** Pushed the architecture specs in a branch
** To do:
⚫
*** Upstream the documents in xen.git
* Features
** Ongoing:
*** Hyperlaunch
*** PCI passthrough
*** virtIO and vPCI
*** Dom0less Domain reset - Xen should be able to reboot a DomU. This may involve saving the kernel and other artefacts and reseting the devices, etc.
** To do:
*** Dom0less vCPU pinning - User should be able to pin a dom0less vcpu to a specific physical cpu
*** Control domain / Hardware domain split - Currently dom0 is the control domain (ie privileged). It can create and destroy other domains and perform special operations. It is also the hardware domain as all the hardware gets assigned to it by default. We wish to split the responsibility between Control domain and hardware domain. IOW, the control domain needs to be separate from the hardware domain. The hardware domain will have the PV or VirtIO backends.
*** XSM module to implement security policy - domctl/sysctl and various hypercalls need to have more granular security controls for different types of domains (control, hardware, driver and domU)




= Roadmap =
= Roadmap =


* Fault injection investigation
* Coverage (gcov and Qemu)
* MCDC Coverage
* Fuzzing
* HW/SW interface investigation
* Boundary value analysis investigation
* Zephyr as Dom0
* Zephyr as Dom0
** tools license issue
** tools license issue
Line 41: Line 67:
** process for change requests of reqs
** process for change requests of reqs
* Tests
* Tests
** traceability
⚫
** coverage
** low level testing
** low level testing

Latest revision as of 15:45, 3 December 2024

Short term Roadmap and ongoing activities

  • Misra compliance
    • Done:
      • Coverity regular analysis (arm)
      • CI internal checks
      • Eclair scanning (Bugseng)
      • MISRA rules in xen.git (partial) with their status
      • MISRA fixes violations
      • Coding style
    • Ongoing:
      • MISRA fixes (or reasoning) for few rules
  • Requirements and Assumption of use
    • Done:
      • Created and defined a hierarchy of requirements (Market, Product and Design)
      • Generic Timer
      • Emulated UART
      • Traceability using OpenFastTrace
    • Ongoing:
      • Dom0less domain creation
      • Device passthrough
      • P2M
    • To do:
      • GICv3, SMMUv3, vGICv3, hyper calls, IOMMU, LAPIC, hypercalls
      • a way to trigger updating the rules in case of code changes
  • Architecture specifications
    • Done:
      • Pushed the architecture specs in a branch
    • To do:
      • Upstream the documents in xen.git
  • Features
    • Ongoing:
      • Hyperlaunch
      • PCI passthrough
      • virtIO and vPCI
      • Dom0less Domain reset - Xen should be able to reboot a DomU. This may involve saving the kernel and other artefacts and reseting the devices, etc.
    • To do:
      • Dom0less vCPU pinning - User should be able to pin a dom0less vcpu to a specific physical cpu
      • Control domain / Hardware domain split - Currently dom0 is the control domain (ie privileged). It can create and destroy other domains and perform special operations. It is also the hardware domain as all the hardware gets assigned to it by default. We wish to split the responsibility between Control domain and hardware domain. IOW, the control domain needs to be separate from the hardware domain. The hardware domain will have the PV or VirtIO backends.
      • XSM module to implement security policy - domctl/sysctl and various hypercalls need to have more granular security controls for different types of domains (control, hardware, driver and domU)


Roadmap

  • Fault injection investigation
  • Coverage (gcov and Qemu)
  • MCDC Coverage
  • Fuzzing
  • HW/SW interface investigation
  • Boundary value analysis investigation
  • Zephyr as Dom0
    • tools license issue
    • what functionalities do we actually need ?
  • Configuration
    • per-domain Xen heap static allocation
    • configurability (strip down code)
  • Real-time
    • communication LinuxRT - Zephyr
    • code improvements
      • remove RCU
  • Code quality
    • Misra-C compliance
      • automatic checks on builds
      • check on patches submitted
      • include the rules in the coding style
    • use of a certified compiler
  • Documentation and requirements
    • process for change requests of reqs
  • Tests
    • low level testing
Retrieved from "https://wiki.xenproject.org/index.php?title=FuSa_SIG/Roadmap&oldid=20061"