FuSa SIG/Roadmap: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
No edit summary
Line 33: Line 33:
*** PCI passthrough
*** PCI passthrough
*** virtIO and vPCI
*** 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.
*** Domain reset
** To do:
** To do:
*** vCPU pinning
*** 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 =

Revision as of 11:33, 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
  • 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