Difference between revisions of "Automotive Whitepapers"

From Xen
Line 5: Line 5:
 
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}}
 
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}}
   
* [[:File:Device_passthrough_xen.pdf|Device Passthrough to Driver Domain in Xen]] by Denys Drozdov ''2015-03-10, GlobalLogic''
+
* [[:File:RT-Xen on ARM.pdf|RT-Xen on ARM]] by Denys Drozdov ''2015-03-10, GlobalLogic''
 
{{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}}
 
{{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}}
 
[[Category:Embedded and Automotive PV Drivers]]
 
[[Category:Embedded and Automotive PV Drivers]]

Revision as of 14:14, 3 April 2015

As modern ARM SoCs become faster and faster, they are now capable of performing the same high­load tasks that desktop PCs were performing a few years ago, such as HD video playback and high­speed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and co­processors that are designed to help with high­load tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.
As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.
The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.