Test page: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= Xen as Static Partitioning Hypervisor for Embedded and Automotive = |
= Xen as Static Partitioning Hypervisor for Embedded and Automotive = |
||
Xen |
You might already know that Xen powers some of the largest clouds in production today, but did you know that Xen is also an excellent static partitioning hypervisor for embedded applications? |
||
Xen can be configured for embedded '''static partitioning''' using '''Dom0less''' and the '''null scheduler'''. |
|||
| ⚫ | |||
'''Dom0less''' enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions. |
|||
[[File:Dom0less.jpg]] |
|||
| ⚫ | Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to [https://gitlab.com/xen-project/imagebuilder ImageBuilder]. |
||
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you. |
The '''null scheduler''' is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding ''sched=null'' to the Xen command line, which ImageBuilder does automatically for you. |
||
Use Dom0less and the null scheduler together to achieve a true static partitioning configuration. |
|||
= Cache Coloring and Deterministic Interrupt Latency = |
= Cache Coloring and Deterministic Interrupt Latency = |
||
If you need |
If you need fully deterministic interrupt latency and hard real-time, a shared L2 cache across CPU cores can be a vehicle for interference. Xen solves the problem by splitting the L2 cache in software using a technology called "Cache Coloring". Xen with Cache Coloring has a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+, even under heavy interference from multiple sources. |
||
Checkout the original [https://www.youtube.com/watch?v=KhESjhUzyj8 Cache Coloring presentation] for more details. |
Checkout the original [https://www.youtube.com/watch?v=KhESjhUzyj8 Cache Coloring presentation] for more details. |
||
| Line 17: | Line 25: | ||
= Xen Safety-Certifications = |
= Xen Safety-Certifications = |
||
Multiple safety assessors from well-known companies in the safety industry have evaluated Xen and deemed it safety-certifiable. |
|||
Xen is safety-certifiable, as stated by multiple well-respected safety assessors in the safety industry. However, work is required to take an upstream Xen release and safety-certify it. There is an active working group, named Xen FuSa SIG (Special Interest Group), with the goal of making upstream Xen releases easier to safety-certify by users and other downstreams. The Xen FuSa SIG is working on a number of activities to better align upstream Xen with safety requirements, including documentation and testing. Currently the Xen FuSa SIG is improving MISRA C compatibility of the Xen codebase and introducing more tests to validate Xen external interfaces. |
|||
If you are interested in safety certifications, join the [https://lists.xenproject.org/mailman/listinfo/fusa-sig Xen FuSa Special Interest Group] or watch one of the [https://wiki.xenproject.org/wiki/FuSa_SIG/Presentations latest presentations]. |
|||
The Xen FuSa SIG has the specific goal of making upstream Xen releases easier to safety certify. The working group is active in a number of areas, from documentation to testing and traceability. Specific examples of Xen FuSa SIG activities are MISRA C compatibility improvements and the introduction of more tests to validate Xen external interfaces. |
|||
Revision as of 23:56, 6 October 2022
Xen as Static Partitioning Hypervisor for Embedded and Automotive
You might already know that Xen powers some of the largest clouds in production today, but did you know that Xen is also an excellent static partitioning hypervisor for embedded applications?
Xen can be configured for embedded static partitioning using Dom0less and the null scheduler.
Dom0less enables Xen to create multiple VMs in parallel at boot without any Dom0 interactions.
Boot times become much shorter, making it easy to achieve sub-second boot times for an RTOS on top of Xen. Dom0 becomes just optional: it could be removed entirely, or a small RTOS could be used as Dom0 just for monitoring the system. For a quick way to setup Dom0less, refer to ImageBuilder.
The null scheduler is hard real-time scheduler that statically assign physical CPUs to virtual CPUs. With the null scheduler, there are no context switches and you get the best possible interrupt latency. Enabling the null scheduler is as easy as adding sched=null to the Xen command line, which ImageBuilder does automatically for you.
Use Dom0less and the null scheduler together to achieve a true static partitioning configuration.
Cache Coloring and Deterministic Interrupt Latency
If you need fully deterministic interrupt latency and hard real-time, a shared L2 cache across CPU cores can be a vehicle for interference. Xen solves the problem by splitting the L2 cache in software using a technology called "Cache Coloring". Xen with Cache Coloring has a deterministic interrupt latency of 4 microseconds on Xilinx Ultrascale+, even under heavy interference from multiple sources.
Checkout the original Cache Coloring presentation for more details.
Xen Safety-Certifications
Multiple safety assessors from well-known companies in the safety industry have evaluated Xen and deemed it safety-certifiable.
If you are interested in safety certifications, join the Xen FuSa Special Interest Group or watch one of the latest presentations.
The Xen FuSa SIG has the specific goal of making upstream Xen releases easier to safety certify. The working group is active in a number of areas, from documentation to testing and traceability. Specific examples of Xen FuSa SIG activities are MISRA C compatibility improvements and the introduction of more tests to validate Xen external interfaces.
