MultiPARTES. Virtualization on Heterogeneous Multicore Platforms. 2012/7/18 Slides by TU Wien, UPV, fentiss, UPM

Transcription

1 MultiPARTES Virtualization on Heterogeneous Multicore Platforms 2012/7/18 Slides by TU Wien, UPV, fentiss, UPM

2 Contents Analysis of scheduling approaches Virtualization of devices Dealing with heterogeneous cores Fault hypothesis Security policy & security model

3 Analysis of scheduling approaches Embedded systems often have tasks with real-time requirements periodic or sporadic execution hard or soft deadlines Scheduling the execution of the tasks on the available processor is crucial in order to guarantee the timing requirements especially in high-integrity systems Two aspects of scheduling decide which tasks run at every time analyze feasibility of real-time requirements 3

4 Basic scheduling approaches Static table-driven scheduling schedule built off-line (e.g. cyclic executive) feasibility guaranteed by construction Static priority scheduling feasibility test off-line (e.g. FPPS/RTA) Dynamic planning-based scheduling on-line feasibility test, dynamic priorities Dynamic best-effort no feasibility test, no guarantees 4

5 Scheduling partitioned systems Temporal separation is needed Server-based approach a server is a container for a partition global scheduling of servers and tasks flexible but complex Hierarchical approach a global scheduler allocates processor time to partitions (e.g. with a static table-driven method) a local scheduler allocates processor time to tasks within a partition (e.g. with a FPPS method) 5

6 Multiprocessor/multicores No clear results for hard-real time systems scheduling & feasibility analysis NP-hard static allocation of hard real-time tasks to processors is commonly used More flexible approaches are possible for soft real-time systems global scheduling with task migration Mixed approaches are possible static allocation of partitions to processors static global scheduling of partitions local schedulers according to requirements 6

7 Virtualization of devices How can devices be shared by multiple partitions? Partition Partition Partition Device Device

8 Device Assignment A device is assigned to a partition Memory mapped region Interrupt line Direct device management Bypass hypervisor I/O Space or memory mapped device Partition XtratuM interrupt Device

9 Device Virtualization (Hypervisor) The hypervisor implements the device driver An interface is offered (hypercalls) Allows the use of the device by several partitions Complex devices not implemented inside XtratuM Only UART and console VGA Partition XtratuM device interface driver Device

10 Device Virtualization Architecture A device is assigned to a server partition The server implements and offers a virtual device to clients Virtual devices resemble multiplexers I/O Server Partition I/O Client Partition I/O Client Partition virtual device virtio driver virtio driver transport layer transport layer transport layer Device shared memory shared memory

11 Device Virtualization Examples Block device virtualization Network virtualization

12 Dealing with heterogeneous multi-core architectures Partitions on architecture A I/O Partitions Partitions on architecture B

13 Scheduling Communication

14 Scheduling Communication

15 Major Frame Synchronisation On-board cloc

16 Contents of the fault hypothesis Unit of failure Definition of Fault Containment Regions (FCRs) Failure modes e.g., fail crash, fail stop, symmetric, byzantine Total number of faults Rate of arrival 16

17 Fault Containment Region A fault containment region (FCR) can be defined as: a set of components that is considered to fail (a) as an atomic unit, and (b) in a statistically independent way with respect to other such FCRs A fault in an FCR has no direct impact on any other FCR The only possible propagation is via the specified interfaces between any FCRs (i.e. error propagation) 17

18 Error Containment Region Errors can propagate by an erroneous message of a faulty FCR to another FCR An Error Containment Region (ECR) contains errors of the constituting FCRs. It will either output a correct value, or will indicate that the output is incorrect An ECR has to consist of at least two FCRs (nobody can prove its own sanity) The failure modes of the FCRs influence the number of required FCRs in an ECR 18

19 FCRs in MultiPARTES We distinguish between two fundamentally different viewpoints according to the class of faults Systematic design faults Random hardware faults FCRs are defined differently for both classes 19

20 Systematic design faults Design faults in the application or guest operating system Each partition constitutes a single FCR The basic assumption is that the hardware and the hypervisor itself is free of design faults Hypervisor has the same certification requirements as the most critical partition! 20

21 Random hardware faults Faults that occur during system operation or the manufacturing process e.g., Single Event Upsets (SEUs) due to electromagnetic interference or radiation or aging Common mode failures cannot be avoided on a single die e.g., shared power supply, clock, package, spatial proximity For ultra-dependable systems the entire chip has to be considered as an FCR HW faults have to be tolerated by hardware redundacy 21

22 Example Traditional Design 10 Subsystems ECRs with Triple Modular Redundancy (TMR) 30 nodes in total required 22

23 Example MultiPARTES Approach 10 Subsystems ECRs with Triple Modular Redundancy (TMR) Subsystems share nodes Nodes are replicated 3 nodes in total required 23

24 Security Modeling Security Policy collection of requirements that describe entities and objects and the mapping of allowed actions between them Security Model mechanisms to enforce the security policy 24

25 MultiPARTES Security Policy The hypervisor has access to the whole memory area (including all data of the communication channels) and all devices Partitions are allowed access to their own memory areas, devices and access to communication channels with some specified other partitions Partitions constitute Intrusion Containment Regions (ICRs) Defined in analogy to FCRs 25

26 MultiPARTES Security Model The hypervisor is loaded by a secure boot process The hypervisor's memory content is protected by the MMU Processing resources are protected by virtualizing the hardware state and the cyclic scheduler By using the MMU and not sharing memory without an indirection through the hypervisor, partition's memory content is protected Devices are not directly shared by multiple partitions. If multiple partitions require access to a device, the access must be performed via the IPC mechanisms and a dedicated server partition 26