Test page: Difference between revisions
(Created page with "= Xen as Static Partitioning Hypervisor for Embedded and Automotive = Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' a...") |
No edit summary |
||
| Line 3: | Line 3: | ||
Xen can be configured to work as an embedded '''static partitioning''' hypervisor using '''Dom0less''' and the '''null scheduler'''. |
Xen can be configured to work as an embedded '''static partitioning''' hypervisor 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. |
'''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|https://gitlab.com/xen-project/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. |
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. |
||
| Line 11: | Line 11: | ||
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+ even under heavy interference from multiple sources. |
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides a '''deterministic interrupt latency of 4 microseconds''' on Xilinx Ultrascale+ even under heavy interference from multiple sources. |
||
Checkout the original [[Cache Coloring presentation|https://www.youtube.com/watch?v=KhESjhUzyj8]] for more details. |
|||
= Xen Safety-Certifications = |
= Xen Safety-Certifications = |
||
Xen is |
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. |
||
Revision as of 23:07, 6 October 2022
Xen as Static Partitioning Hypervisor for Embedded and Automotive
Xen can be configured to work as an embedded static partitioning hypervisor 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 https://gitlab.com/xen-project/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.
Cache Coloring and Deterministic Interrupt Latency
If you need a fully deterministic interrupt latency or hard real-time, a shared L2 cache across CPU cores assigned to different VMs can be a vehicle for interference. Xen can solve the problem for you by splitting the L2 cache in software using a technology called "cache coloring". With Cache Coloring, Xen provides 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 for more details.
Xen Safety-Certifications
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.
