SUPERVISION SYSTEM IN A SYSTEM-ON-A-CHIP (SoC) TO ARBITRATE EXECUTION BEHAVIOR OF APPLICATIONS EXECUTED BY VIRTUAL MACHINES (VMs) TO RESOLVE CONFLICTS TO SHARED RESOURCES, AND RELATED METHODS

Abstract

Supervision system in a system-on-a-chip (SoC) to arbitrate execution behavior of applications executed by respective multiple VMs to resolve conflicts to shared computing resources in the SoC, and related methods. The SoC also includes a supervision system that operates independently of a hypervisor that controls scheduling of execution of the VMs. The supervision system is configured to arbitrate the execution behavior of the applications to resolve conflicts to shared computing resources accessed in the SOC as a result of executing applications in the SoC. To resolve shared computing resource conflicts, the supervision system is configured to arbitrate the execution behavior of applications based on the monitored status indicators. The supervision system could decide to terminate, modulate (e.g., decrease or increase scheduling priority), and / or re-schedule (e.g., delay) execution of an application (s) so that certain applications may have decreased or increased access to shared computing resources to resolve shared computing resource conflicts.

Description

SUPERVISION SYSTEM IN A SYSTEM-ON-A-CHIP (SoC) TO ARBITRATE EXECUTION BEHAVIOR OF APPLICATIONS EXECUTED BY VIRTUAL MACHINES (VMs) TO RESOLVE CONFLICTS TO SHARED RESOURCES, AND RELATED METHODSTECHNICAL FIELD

[0001] The technology of the disclosure relates to processor-based systems, and more particularly to systems-on-a-chip (SoCs) that support hosting of a virtual machine (s) (VM(s) ) supervised by a hypervisor for providing organized functionalities and operations with access to shared computing resources in the SoC.BACKGROUND

[0002] The integration of virtual machines (VMs) with hypervisors in a system-on-a-chip (SoC) heralds a new era of computing innovation, offering a potent combination of hardware consolidation and software abstraction. With hypervisor support embedded directly into a chip architecture, developers gain unprecedented flexibility in designing and deploying complex, heterogeneous systems, spanning diverse application domains, such as edge computing, automotive electronics, industrial automation, and smart infrastructure. Moreover, by leveraging virtualization technology at the silicon level, SoC-based platforms can achieve greater efficiency and performance optimization, while simultaneously reducing hardware costs and power consumption. As the demand for intelligent, connected devices continues to surge, SoCs equipped with virtualization capabilities are poised to play a pivotal role in driving the next wave of innovation, ushering in a future where computing resources are seamlessly orchestrated and dynamically allocated to meet the evolving needs of modern society.

[0003] A SoC can include multiple processors (neural signal processor (NSP) , graphics processing unit (GPU) , etc. ) and dedicated and shared hardware resources to perform tasks. VMs can be executed in a central processing unit (s) (CPU (s) ) on the SoC to access the multiple processors and hardware resources to perform tasks. The VMs can be organized according to functionalities and operations that make sense according to the design and application of the processor-based system. For example, in an automotive application, one VM may be set up to handle in-vehicle infotainment applications (e.g., driver monitoring system, displays, audio, cloud services) , while another VM may be set up to handle driving assistance applications (e.g., automotive visible perception, drive  policy, and parking viewing) . A hypervisor can schedule the VMs in and out to access shared hardware, but sometimes conflicts can arise in accessing shared computing resources. For example, a particular application may have a massive computing load in an NSP for a short time, and thus, another application may not be able to obtain access to the NSP at a given time.

[0004] SUMMARY OF THE DISCLOSURE

[0005] Aspects disclosed herein a supervision system in a system-on-a-chip (SoC) to arbitrate execution behavior of applications executed by respective multiple virtual machines (VMs) to resolve conflicts to shared computing resources in the SoC. Related methods are also disclosed. The SoC is configured to support multiple VMs that are each configured to control a central processing unit (CPU) to execute specific applications autonomously from a design perspective for reduced design complexity, but with access to shared hardware resources in the SoC (e.g., specialized processors, memory systems, etc. ) for reduced cost and area. To avoid shared computing resource conflicts between the multiple applications executed in the SoC, the SoC also supports a hypervisor to control scheduling of switching in and out of the VMs to the CPU. For example, conflicts in shared computing resources can include certain applications being starved or unduly delayed from accessing a shared computing resource to perform its designed function. Even with the use of the hypervisor, shared computing resource conflicts can still arise (e.g., one application controlled by a VM being starved because of execution of another application controlled by another VM with a higher computing load) .

[0006] In this regard, in exemplary aspects, the SoC also includes a supervision system that operates independently of the hypervisor. The supervision system is configured to arbitrate (i.e., control and possibly adjust) the execution behavior of the applications to resolve conflicts to shared computing resources accessed in the SoC as a result of executing applications in the SoC. Execution behavior represents or corresponds to the occupation of shared computing resources of respective applications as a result of their execution in the SoC that can result in conflicts in other applications being able to sufficiently access the shared computing resources according to their needs. Execution behavior of applications can include the behavior of to-be-scheduled applications, behavior of applications scheduled for execution, and behavior of executing applications,  as examples. For example, the supervision system can be program code that can be provided as built-in functionality in an operating system (OS) executed by a CPU in the SoC. The supervision system may operate as a separate VM in the SoC. The supervision system arbitrates the execution behavior of applications in the SoC to resolve shared computing resource conflicts. The supervision system includes a monitoring system configured to monitor status indicators that affect performance of the SoC and the applications executing in the SoC as it pertains to accessing shared computing resources. For example, such status indicators can be system-level indicators (e.g., temperature information, power information) , platform resource indicators (i.e., information on availability of a shared computing resource (e.g., a particular shared processor bandwidth, memory system bandwidth) ) , and / or application indicators (e.g., execution failure information, execution delay information) . While each of these status indicators indicate individualized status information regarding the SoC or an application, use of these status indicators in combination may indicate resource conflicts that may not otherwise be determinable from an individual status indicator. For example, a system indicator indicating a higher thermal condition in combination with a known activity level of an application from its application indicator may indicate a resource conflict that would not otherwise exist under lower thermal conditions. To resolve resource conflicts, the supervision system is configured to arbitrate the execution behavior of applications based on the monitored status indicators. For example, the supervision system could decide to terminate, modulate (e.g., decrease or increase scheduling priority) , and / or re-schedule (e.g., delay) execution of an application (s) so that certain applications may have decreased or increased access to shared computing resources to resolve resource conflicts. In this manner, regardless of how the hypervisor schedules VMs in and out to execute its respective applications in the SoC, the supervision system can further alter the execution behavior of such applications to further resolve resource conflicts.

[0007] In another exemplary aspect, the SoC is designed for automotive applications, wherein a single SoC is configured to execute applications for different systems within a vehicle. For example, the SoC may support an in-vehicle infotainment system (e.g., driver monitoring system, displays, audio, cloud services) , and a separate driving assistance system (e.g., automotive visible perception, drive policy, and parking viewing) , with each being executed by respective VMs executed in the SoC. A hypervisor  executing in the SoC controls the switching in and out of the in-vehicle infotainment VM and driving assistance VM for their respective applications to be executed, which may involve access to shared computing resources in the SoC. The SoC also includes a supervision system that operates independently of the hypervisor, and is configured to resolve resource conflicts in shared computing resources accessed by applications executing in the SoC by arbitrating the execution behavior of the applications executed by the in-vehicle infotainment VM and driving assistance VM. The supervision system arbitrates the execution behavior of applications executed by the in-vehicle infotainment VM and driving assistance VM in the SoC to resolve shared computing resource conflicts based on monitored status indicators. The supervision system may operate like the supervision system described above.

[0008] In another exemplary aspect, multiple VMs supported in the SoC include their own respective supervision systems configured to arbitrate the execution behavior of their applications to resolve shared computing resource conflicts in the SoC. For example, a host VM may include a master supervision system that may be configured to arbitrate the execution behavior of its applications. Another guest VM (GVM) can also be supported by the SoC that includes a guest supervision system configured to arbitrate the execution behavior of its guest applications. For example, the host VM may be a driving assistance VM that includes the master supervision system, and the GVM may be an in-vehicle infotainment VM that includes a guest supervision system. In this manner, the supervision system functionality is distributed among the multiple VMs that can each have different OSs. As an example, the host VM may be supported by an ANDROID OS, and the GVM supported by a separate OS. The master supervision system can be configured to not only arbitrate the execution behavior of the applications in its VM, but also communicates arbitration requests to the guest supervision system in the guest VM to arbitrate the execution behavior of the guest applications. In this manner, the master supervision system can control the overall consumption of the shared computing resources to manage any resource conflicts by arbitrating the execution behavior of its applications and also coordinating the guest supervision system to arbitrate the execution behavior of its guest applications.

[0009] In this regard, in one exemplary aspect, a SoC is disclosed. The SoC includes one or more shared computing resource circuits. The SoC also includes a CPU configured  to execute a hypervisor to schedule execution of a plurality of VMs comprising a plurality of applications to be executed. The CPU is configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed. The SoC also includes a supervision system. The supervision system includes a monitoring module. The monitoring module is configured to receive one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits. The monitoring module is also configured to receive one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits. The supervision system also includes an arbitration module. The arbitration module is configured to determine a conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators. The arbitration module is also configured to determine an execution behavior of at least one application of the plurality of applications to resolve the determined conflict. The arbitration module is also configured to arbitrate the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0010] In another exemplary aspect, a method of controlling execution behavior of applications of VMs executed in a SoC is disclosed. The SoC includes one or more shared computing resource circuits. The SoC also includes a CPU configured to execute a hypervisor to schedule execution of a plurality of VMs comprising a plurality of applications to be executed. The CPU is configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed. The method includes receiving one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits. The method also includes receiving one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits. The method also includes determining a conflict in the one or more shared computing resource circuits resulting from the  execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators. The method also includes determining an execution behavior of at least one application of the plurality of applications to resolve the determined conflict. The method also includes arbitrating the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0011] BRIEF DESCRIPTION OF THE FIGURES

[0012] Figure 1 is a block diagram of an exemplary processor-based system in a system-on-a-chip (SoC) that includes a central processing unit (CPU) configured to supports a supervision system to arbitrate execution behavior of applications executed by respective multiple virtual machines (VMs) executed in the SoC based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC;

[0013] Figure 2 is a block diagram illustrating another SoC that includes multiple VMs executed in the SoC in Figure 1 under control of a hypervisor, and wherein the SoC supports a supervision system that is configured to arbitrate execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC;

[0014] Figure 3 is a block diagram illustrating more exemplary detail of the supervision system in Figure 2, wherein the supervision system is configured to arbitrate execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC;

[0015] Figure 4 is a flowchart illustrating an exemplary process of a supervision system arbitrating execution behavior of applications executed by VMs in a SoC based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC, including, but not limited to, the supervision systems in Figures 2 and 3;

[0016] Figure 5 is a block diagram illustrating another exemplary supervision system that can be the supervision system supported in the SoC in Figures 1 and 2, wherein the supervision system is configured to receive monitored status indicators based on execution of vehicle control related applications in the SoC, and wherein the supervision system is configured to arbitrate the execution behavior of driver assistance system (DAS)  applications executed in the SoC based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC;

[0017] Figure 6 is a block diagram another exemplary supervision system that can be the supervision system supported in the SoC in Figures 1 and 2, wherein the supervision system includes a main supervision system executed in the SoC and configured to receive monitored status indicators based on execution of DAS applications in the SoC, and a guest supervision system executed in the SoC and configured to receive monitored status indicated based on execution of in-vehicle infotainment (IVI) applications in the SoC, wherein the host and guest supervision systems coordinate with each other to arbitrate execution behavior of respective DAS and IVI applications based on the monitored status indicators in the SoC, to resolve conflicts to shared computing resources in the SoC;

[0018] Figure 7 is a block diagram of an exemplary processor-based system included in a SoC, wherein the SoC can support multiple VMs executed under control of a hypervisor, and wherein the SoC supports a supervision system (s) , including, but not limited, to the supervision systems in Figures 2-3 and 5-6, configured to arbitrate execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC, and according to, but not limited to, the exemplary process in Figure 4;

[0019] Figure 8 is a block diagram of an exemplary wireless communications device that includes radio-frequency (RF) components that can be included in a SoC, wherein the SoC can support multiple VMs executed under control of a hypervisor, and wherein the SoC supports a supervision system (s) , including, but not limited to, the supervision systems in Figures 2-3 and 5-6, configured to arbitrate execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC, and according to, but not limited to, the exemplary process in Figure 4.DETAILED DESCRIPTION

[0020] With reference now to the drawing figures, several exemplary aspects of the present disclosure are described. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0021] Aspects disclosed herein a supervision system in a system-on-a-chip (SoC) to arbitrate execution behavior of applications executed by respective multiple virtual machines (VMs) to resolve conflicts to shared computing resources in the SoC. Related methods are also disclosed. The SoC is configured to support multiple VMs that are each configured to control a central processing unit (CPU) to execute specific applications autonomously from a design perspective for reduced design complexity, but with access to shared hardware resources in the SoC (e.g., specialized processors, memory systems, etc. ) for reduced cost and area. To avoid shared computing resource conflicts between the multiple applications executed in the SoC, the SoC also supports a hypervisor to control scheduling of switching in and out of the VMs to the CPU. For example, conflicts in shared computing resources can include certain applications being starved or unduly delayed from accessing a shared computing resource to perform its designed function. Even with the use of the hypervisor, shared computing resource conflicts can still arise (e.g., one application controlled by a VM being starved because of execution of another application controlled by another VM with a higher computing load) .

[0022] In this regard, in exemplary aspects, the SoC also includes a supervision system that operates independently of the hypervisor. The supervision system is configured to arbitrate (i.e., control and possibly adjust) the execution behavior of the applications to resolve conflicts to shared computing resources accessed in the SoC as a result of executing applications in the SoC. Execution behavior represents or corresponds to the occupation of shared computing resources of respective applications as a result of their execution in the SoC that can result in conflicts in other applications being able to sufficiently access the shared computing resources according to their needs. Execution behavior of applications can include the behavior of to-be-scheduled applications, behavior of applications scheduled for execution, and behavior of executing applications, as examples. For example, the supervision system can be program code that can be provided as built-in functionality in an operating system (OS) executed by a CPU in the SoC. The supervision system may operate as a separate VM in the SoC. The supervision system arbitrates the execution behavior of applications in the SoC to resolve shared computing resource conflicts. The supervision system includes a monitoring system configured to monitor status indicators that affect performance of the SoC and the applications executing in the SoC as it pertains to accessing shared computing resources.  For example, such status indicators can be system-level indicators (e.g., temperature information, power information) , platform resource indicators (i.e., information on availability of a shared computing resource (e.g., a particular shared processor bandwidth, memory system bandwidth) ) , and / or application indicators (e.g., execution failure information, execution delay information) . While each of these status indicators indicate individualized status information regarding the SoC or an application, use of these status indicators in combination may indicate resource conflicts that may not otherwise be determinable from an individual status indicator. For example, a system indicator indicating a higher thermal condition in combination with a known activity level of an application from its application indicator may indicate a resource conflict that would not otherwise exist under lower thermal conditions. To resolve resource conflicts, the supervision system is configured to arbitrate the execution behavior of applications based on the monitored status indicators. For example, the supervision system could decide to terminate, modulate (e.g., decrease or increase scheduling priority) , and / or re-schedule (e.g., delay) execution of an application (s) so that certain applications may have decreased or increased access to shared computing resources to resolve resource conflicts. In this manner, regardless of how the hypervisor schedules VMs in and out to execute its respective applications in the SoC, the supervision system can further alter the execution behavior of such applications to further resolve resource conflicts.

[0023] In this regard, Figure 1 is a block diagram of an exemplary processor-based system 100 provided as a system-on-a-chip (SoC) 102. As discussed in more detail below, the SoC 102 is configured to support a supervision system to arbitrate execution behavior of applications executed by respective multiple virtual machines (VMs) executed in the SoC 102 based on monitored status indicators in the SoC 102 to resolve conflicts to shared computing resources in the SoC 102. As shown in Figure 1, the SoC 102 includes a CPU 104 that includes one or more processors each with one or more CPU cores for execution program code to carry out tasks within the SoC 102. A benefit of providing the processor-based system 100 in the SoC 102 is that the SoC 102 can include other specialized processors on-chip that can be utilized by the CPU 104 to perform specialized tasks in a highly efficient manner. In this example, the SoC 102 includes an image signal processor (ISP) 106 which is a media processor configured to process image data that is captured from an imaging device interfaced with the SoC 102, such as a  camera. The SoC 102 also includes a vector processing unit (VPU) 108, a graphic processing unit (GPU) 110, and digital signal processors (DSPs) 112, 114. These processors may be shared computing resources that can be accessed through execution of an application by the CPU 104 to perform specific tasks.

[0024] With continuing reference to Figure 1, the SoC 102 in this example also includes a multimedia circuit 116 that is configured to interface with an external serialization / de-serialization circuit 118 to stream media data in and out of the SoC 102. The multimedia circuit 116 is a shared computing resource in the SoC 102. The SoC 102 also includes a memory system 120 that includes a cache memory 122, internal memory 124, and a universal flash storage (UFS) interface circuit 126 for interfacing with an external flash memory drive 128 to send and receive data to be stored and / or accessed from the flash memory drive 128. The memory system 120 also includes a memory controller 130 that is configured to be used to provide access by the CPU 104 to the memory system 120, and to an external system memory 132 (e.g., dynamic random access memory (DRAM) ) through a memory interface 133. The memory system 120 is a shared computing resource in the SoC 102. The SoC 102 also includes a safety island (SAIL) system 134 that is configured to manage faults and control the rest of the SoC 102 to enable recovery from chip and signal failures. The SoC 102 also includes a connectivity system 136 that includes interface circuits configured to interface with external circuits, which in this example include a vehicle interface processor 138, a coded circuit 140, a software defined radio 142, and an ethernet switch / transceiver 144. For example, the SoC 102 may be designed specifically for a vehicle or automotive application to provide a computing resource to control vehicle functions through the vehicle interface processor 138. The connectivity system 136 is a shared computing resource in the SoC 102. The SoC 102 also includes system resources 146 that provide internal functions, such as thermal sensors 148 for sensing temperature in the SoC 102, clock generation circuits 150 for generating clock signals, a power management circuit 152 for regulating voltage and power supplied in the SoC 102, boot registers 154 for being configured for boot-up modes and reset operations, and security circuits 156 for providing security features and functions in the SoC 102.

[0025] For example, Figure 2 is a block diagram illustrating another processor-based system 200 that could be the processor-based system 100 in Figure 1, and which includes  a SoC 202 that could be the SoC 102 in Figure 1. For the purposes of this discussion, it is assumed that the SoC 202 includes the components in the SoC 102 in Figure 1 that can be referenced by the element numbers in Figure 1. The processor-based system 200 is configured to support multiple VMs 203 (1) -203 (X) being executed by the CPU 104 to access the various shared computing resources provided in the SoC 202, as discussed above. The VMs 203 (1) -203 (X) each include one or more applications 205 that are configured to be scheduled to be executed by the CPU 104 as part of executing its VM 203(1) -203 (X) . The VMs 203 (1) -203 (X) can be organized according to functionalities and operations that make sense according to the design and application of the processor-based system 100.

[0026] In this example processor-based system 200 in Figure 2, multiple VMs 203 (1) -203(X) that each include one or more applications 205 are supported in the SoC 202 for their applications 205 to be executed by the CPU 104. In this example, a first VM 203 (1) includes a driver assistance system (DAS) 204 that includes applications 205 as an automotive vision perception (AVP) application 206, a drive policy (DP) application 208, and a viewing parking application 210. Each of these DAS applications 206, 208, 210 is represented by computer program code that can be executed by the CPU 104 and / or a specialized processor 106-114 when the first VM 203 (1) is switched in the CPU 104 for execution. Also in this example, the first VM 203 (1) supported in the SoC 202 for execution by the CPU 104 also includes an in-vehicle infotainment (IVI) system 212 that includes applications 205 as a driver monitoring system (DMS) application 214, a display application 216, an audio application 218, and a cloud storage interface application 220. Each of these IVI applications 214, 216, 218, 220 is represented by computer program code that can be executed by the CPU 104 and / or a specialized processor 106-114 when the first VM 203 (1) is switched in the CPU 104 for execution.

[0027] In this example, the DAS 204 and the IVI system 212 may each have their own respective operating system (OS) 224, 226 that is configured to be executed by the CPU 104 and schedule execution of their respective applications 206-210, 214-220. For example, the DAS and IVI systems 204, 212 each having their own OSs 224, 226 (or software platform) may be the result of the DAS and the IVI systems 204, 212 having been previously developed as separate systems that were previously intended to be executed in separate processors, but now with the SoC 202 can be supported in the same  processor-based system 200 and chip of the SoC 202. However, with the integration of the DAS 204 and IVI system 212 in the common SoC 102, 202, in this example, the DAS 204 and IVI system 212, execution of their respective applications 206-210, 214-220 may cause the CPU 104 to access shared computing resource circuits 228 in the SoC 202 to perform programmed tasks, including the shared computing resources outside of the CPU 104 discussed in the SoC 102 in Figure 1.

[0028] As discussed above, the SoC 202 may be configured to support other VMs 203 (2) -203 (X) in addition to or because of the first VM 203 (1) . In this regard, with continuing reference to Figure 2, the CPU 104 is configured to support a hypervisor 222 that is a computer program configured to manage and run the multiple VMs 203 (1) -203 (X) and control the switching in and out of the VMs 203 (1) -203 (X) for their applications 205 to be executed by the CPU 104. Even though the hypervisor 222 can schedule the VMs 203 (1) -203 (X) in and out of the CPU 104 for execution in the SoC 202, conflicts can arise by their applications 205, 206-210, 214-220 accessing the shared computing resource circuits 228 in the SoC 202 (see Figure 1 for example) . For example, a particular application 205 in a VM 203 (2) -203 (X) may have a massive computing load in a specialized processor 106-114 for a short time, and thus, a DAS application 206-210 in the first VM 203 (1) may not be able to obtain access to the same specialized processor 106-114 at a given time thus negatively affecting performance in the SoC 202. However, it may be critical that the DAS applications 206-210 be timely executed in the processor-based system 200 as controlling critical vehicle applications. For example, conflicts to shared computing resource circuits 228 can include certain DAS applications 206-210 being starved or unduly delayed from accessing a shared computing resource circuit 228 in the SoC 202 to perform its designed function. Conflicts to shared computing resource circuits 228 can also include the other applications and IVI applications 214-220 being starved or unduly delayed from accessing a shared computing resource circuit 228 in the SoC 202 to perform its designed function. Even with the use of the hypervisor 222, conflicts by accessing the shared computing resource circuits 228 can still arise (e.g., one application controlled by a VM 203 (1) -203 (X) being starved because of execution of another application controlled by another VM 203 (1) -203 (X) with a higher computing load.

[0029] In this regard, as shown in Figure 2, the SoC 202 in this example includes a supervision system 230. The supervision system 230 includes program code being executed by an OS executing in the CPU 104. The supervision system 230 operates independently of the hypervisor 222. The supervision system 230 is configured to arbitrate (i.e., control and possibly adjust) the execution behavior of the applications 205 in the VMs 203 (1) -203 (X) executed by the CPU 104, including the VM 203 (1) , to resolve conflicts to the shared computing resource circuits 228 accessed in the SoC 202 as a result of executing the applications 205 of the VMs 203 (1) -203 (X) . To arbitrate execution behavior of an application means to control and possibly adjust an execution characteristic of the application (e.g., terminate the application, reschedule the application, change a priority level of the application) , such that it may change how the application occupies a shared computing resource (s) that could affect the ability of other applications to access and occupy the same shared computing resource (s) . Execution behavior represents or corresponds to the occupation of shared computing resources of respective applications as a result of their execution in the SoC that can result in conflicts in other applications being able to sufficiently access the shared computing resources according to their needs. The execution behavior of the applications 205 can include the behavior of to-be-scheduled applications 205, behavior of applications 205 scheduled for execution, and behavior of executing applications 205, as examples. The supervision system 230 arbitrates the execution behavior of applications 205 in the SoC 202 to resolve a conflict (s) in the shared computing resource circuits 228. In this manner, regardless of how the hypervisor 222 schedules a VM 203 (1) -203 (X) in and out to execute its respective applications 205, 206-210, 214-220 in the SoC 202, the supervision system 230 can further alter the execution behavior or such applications 205, 206-210, 214-220 to further resolve shared computing resource conflicts.

[0030] Figure 3 is a block diagram illustrating exemplary detail of the supervision system 230 in Figure 2 that can be provided in the SoCs 102, 202 in Figures 1 and 2, to arbitrate execution behavior of applications 205 executed by VMs 203 (1) -203 (X) to resolve conflicts to shared computing resources in the SoC 202. Figure 4 is a flowchart illustrating an exemplary process 400 of the supervision system 230 arbitrating execution behavior of applications 205 executed by VMs 203 (1) -203 (X) in the SoC 202 based on monitored status indicators in the SoC 202 to resolve conflicts to shared computing  resource circuits 228 in the SoC 202. The process 400 in Figure 4 is discussed below as part of discussing the exemplary supervision system 230 in Figure 3.

[0031] In this example, as shown in Figure 3, the supervision system 230 includes a monitoring module 300 that includes status indicators that provide an indication of the status of a component in the SoC 202 that may be indicative of a conflict to a shared computing resource circuit 228. The monitoring module 300 may be a hardware circuit, a combination of hardware and software, and / or an application 205 executed by the CPU 104, such as in its OS or an OS of a VM 203. In this example, the monitoring module 300 includes status indicators 301 that include one or more system status indicators 302 that each include status information regarding a system resource 146 in Figure 1. For example, the one or more system status indicators 302 could include system status information regarding the SoC 202, such as temperature from the thermal sensors 148, system clock frequency from the clock generation circuits 150, and voltage level or power level from the power management circuit 152. In this example, the monitoring module 300 also includes status indicators 301 that include one or more platform status indicators 304 that could include platform status information indicating the availability status of a shared computing resource circuit (s) 228. For example, a platform status indicator 304 could indicate an amount of memory consumed in the memory system 120 (as shared computing resource circuits 228) by applications 205 of a VM 203 (1) -203 (X) executing in the CPU 104. The platform status indicators 304 could also indicate the available bandwidth of a shared specialized processor 106-114 in the SoC 202 as another example.

[0032] In this example in Figure 3, the monitoring module 300 of the supervision system 230 also includes status indicators 301 that include one or more application status indicators 306 that indicate application status information indicating the status of an application 205 in a VM 203 (1) -203 (X) executing in the CPU 104. For example, an application status indicator 306 could also indicate an application’s 205 inability to have sufficient memory allocated for its execution from the memory system 120. For each of the status indicators 302, 304, 306, such could be registers or other memory structures that are configured to store encoded data indicating status information. The CPU 104 or another processor in the SoC 202 could be responsible for updating the status information in the system status indicators, platform status indicators, and application status indicators 302, 304, 306 on an ongoing basis or based on pushed status information from respective  system resources 146, shared computing resource circuits 228, and / or the applications 205 of the VMs 203 (1) -203 (X) .

[0033] With continuing reference to Figure 3, the supervision system 230 also includes an arbitration module 308. The arbitration module 308 may be a hardware circuit, a combination of hardware and software, and / or an application 205 executed by the CPU 104, such as in its OS or an OS of a VM 203 (1) -203 (X) . The arbitration module 308 is configured to receive the status information from one or more of the platform status indicators 304 each indicating an availability status of a shared computing resource circuit 228 (block 402 in Figure 4) and the application status indicators 306 in the monitoring module 300, indicating a status of an access to a shared computing resource circuit 228 by an application 205 executed by the CPU 104 (block 404 in Figure 4) . The arbitration module 308 may also be configured to receive system status information from the system status indicators 302 in the monitoring module 300. The arbitration module 308 is configured to determine a conflict in the one or more shared computing resource circuits 228 resulting from the execution of one or more applications 205 in a VM 203 (1) -203 (X) executing in the CPU 104 and / or the shared computing resource circuits 228 (block 406 in Figure 4) . In response to determining a conflict, the arbitration module 308 is configured to determine a desired or target execution behavior (which may be a different execution behavior from the current execution behavior) of at least one application 205 executing in the CPU 104 based on the determined conflict (e.g., based on least one predefined rule –e.g., rules discussed below) to try to resolve the shared resource conflict in the SoC 202 (block 408 in Figure 4) , examples of such which will be discussed in more detail below. The supervision system 230 also includes a control module 310 that is provided as part of the arbitration module 308 in this example. The control module 310 may be a hardware circuit, a combination of hardware and software, and / or an application 205 executed by the CPU 104, such as in its OS or an OS of a VM 203. The control module 310 is configured to arbitrate the execution behavior of the at least one application 205 of a VM 203 (1) -203 (X) executing in the CPU 104 based on the determined execution behavior of the at least one application 205 determined to contribute to a shared resource conflict, to try to resolve the shared resource conflict in the SoC 202 (block 410 in Figure 4) .

[0034] With continued reference to Figure 3, in this example, the arbitration module 308 can include application modulation rules 312 that can be consulted to determine how a particular application 205 may be modulated (increased or decreased in execution priority or certain features disabled) based on the system status indicators 302, the platform status indicators 304, and / or the application status indicators 306. The arbitration module 308 can then determine a conflict in a shared computing resource circuit (s) 228 based on the application modulation rules 312 and a target execution behavior of an application 205 to try to avoid such conflict. The arbitration module 308 can also include schedule rules 314 that can be consulted to determine how a particular application 205 can be scheduled based on the system status indicators 302, the platform status indicators 304, and / or the application status indicators 306. The arbitration module 308 can also determine a conflict in a shared computing resource circuit (s) 228 based on the schedule rules 314 and a target execution behavior of an application 205 to try to avoid such conflict. The arbitration module 308 can also include system level strategy rules 316 that can be consulted to determine how a shared resource 146 may be configured based on the system status indicators 302, the platform status indicators 304, and / or the application status indicators 306. The arbitration module 308 can also determine a conflict in a shared computing resource circuit (s) 228 based on the system level strategy rules 316 and a target execution behavior of an application 205 to try to avoid such conflict.

[0035] The control module 310 in the supervision system 230 can take different actions to try to avoid shared computing resource circuit 228 conflicts, based on the determined execution behavior of the application 205 according to one or more predefined rules, such as the application modulation rules 312, schedule rules 314, and system level strategy rules 316. For example, the control module 310 can be configured to arbitrate the execution behavior of an application 205, by being configured to terminate the execution of the application 205 based on the determined execution behavior of the application 205 according to the application modulation rules 312. In another example, the control module 310 can be configured to arbitrate the execution behavior of an application 205, by being configured to change a scheduling priority (increase priority or decrease or lower priority) of an application based on the determined execution behavior of the application 205 according to the schedule rules 314.

[0036] One example of the supervision system 230 in Figure 3 arbitrating execution of an application 205 is the supervision system 230 determining a memory conflict in the memory system 120 (Figure 1) resulting from the execution of applications 205 each accessing the memory system 120, based on a platform status indicator (s) 304 and / or an application status indicator 306. For example, the memory conflict may be determined based on a first application status indicator 306 associated with a first application 205 generating an error code indicating insufficient memory being available in the memory system 120 to support the first application 205. The supervision system 230 can arbitrate the execution behavior of the first application (s) 205 or another application (s) 205 to try to resolve the memory conflict. In another example, the supervision system 230 may determine a memory conflict to the memory system 120 based on a second application (s) 205 consuming memory in the memory system 120 that causes an error code indicating insufficient memory for the second application 205 based on a platform status indicator 304 indicating the memory consumption in the memory system 120 by the second application (s) 205. The supervision system 230 can arbitrate the execution behavior of the second application (s) 205 or another application (s) 205 to try to resolve the memory conflict.

[0037] In another example, the shared computing resource circuit 228 may include a context stack in the CPU 104 that is used for switching in and out contexts of different VMs 203 (1) -203 (X) executed by the CPU 104. The supervision system 230 can be configured to determine a shared resource conflict by being configured to determine a context loading conflict resulting from the execution of the VMs 203 (1) -203 (X) , based a platform status indicator (s) 304 indicating a context loading error for a first VM 203 (1) -203 (X) of a plurality of VMs 203 (1) -203 (X) . The supervision system 230 can determine the execution behavior of an application (s) 205 in the first VM 203 (1) -203 (X) or another VM 203 (1) -203 (X) to resolve the determined context loading conflict.

[0038] In another example, the supervision system 230 can be configured to determine a conflict in a shared computing resource circuit (s) 228 resulting from the execution of applications 205, based on a system status indicator 302. For example, a system status indicator 302 may indicate an excessive temperature conflict from an excessive temperature in the SoC 202 resulting from the execution of the applications 205 by the CPU 104. In this manner, the supervision system 230 may be configured to change  a power mode in the power management circuit 152 to a lower power mode to reduce power consumption to in turn cause the temperature of the SoC 202 to be lowered. The supervision system 230 could be configured to change a voltage level in the power management circuit 152 to a lower voltage to reduce power consumption to in turn cause the temperature of the SoC 202 to be lowered, or lower the frequency of the clock signals generated by the clock generation circuits 150 to reduce power consumption to in turn cause the temperature of the SoC 202 to be lowered, as examples.

[0039] Figure 5 is a block diagram illustrating another exemplary supervision system 530 that can be supported in the SoCs 102, 202 in Figures 1 and 2. The supervision system 530 in Figure 5 is referenced as being able to be the supervision system 230 in Figure 2 in the SoC 202 to arbitrate execution of applications 205 of the DAS 204, but such is not limiting.

[0040] In this regard, as shown in Figure 5, an arbitration module 508 is provided in the form of program code executing in the CPU 104. Like the arbitration module 308 in Figure 3, the arbitration module 508 may also be a hardware circuit, a combination of hardware and software, and / or an application 205 executed by the CPU 104, such as in its OS or an OS of a VM 203. The arbitration module 508 is configured to receive application status indicators 306 (1) from an AVP monitoring component 504 of the AVP application 206 indicating a status of the AVP application 206 of the DAS 204. The arbitration module 508 is also configured to receive application status indicators 306 (2) from a DP monitoring component 506 that may be a process or application of the AVP application 206 indicating a status of the DP application 208 of the DAS 204. These application status indicators 306 (1) , 306 (2) can indicate fault information for the AVP application 206 and DP application 208. The arbitration module 508 is also configured to receive platform status indicators 304 (1) from a computing resource manager 509 that may be a process or application indicating the utilization (e.g., bandwidth) and / or scheduling information of the shared specialized processors 106-114 (Figure 1) .

[0041] The arbitration module 508 is also configured to receive platform status indicators 304 (2) and system status indicators 302 (1) from a sysprofiler 510 that may be a process or application indicating the platform loading in the SoC 202, temperature from the thermal sensors 148, memory system 120, and connectivity system 136 as examples. The arbitration module 508 is also configured to receive a system status indicator 302 (2)  from a power management component 512 interfaced with the SoC 202 indicating the power status in the SoC 202 as an example. The arbitration module 508 may also be configured to receive a platform status indicator 304 (3) from a network quality of service (QoS) component 514 that may be a process or application indicating a QoS of the memory interface 133 in the SoC 202. The arbitration module 508 may also be configured to receive a system status indicator 302 (3) from an alarm component 516 that may be a process or application indicating system alarms in the SoC 202. As an example, the system status indicators 302 (1) -302 (3) , platform status indicators 304 (1) -304 (3) , and application status indicators 306 (1) -306 (2) can be pushed to the arbitration module 508 or periodically polled by the arbitration module 508, such as every fifty (50) milliseconds (ms) .

[0042] The arbitration module 508 is configured to determine a conflict in a shared computing resource circuit (s) 228 based on the system status indicators 302 (1) -302 (3) , platform status indicators 304 (1) -304 (3) , and application status indicators 306 (1) -306 (2) . The arbitration module 508 can then determine an execution behavior of the AVP application 206 and / or the DP application 208 based on the determined conflict in a shared computing resource circuit (s) 228 based on the system status indicators 302 (1) -302 (3) , platform status indicators 304 (1) -304 (3) , and application status indicators 306 (1) -306 (2) , and based on at least one predefined rule for resolving the determined conflict. The arbitration module 508 can then arbitrate the execution behavior of the AVP application 206 and / or the DP application 208 of the DAS 204 based on the determined execution behavior of the AVP application 206 and / or the DP application 208. The determined execution behavior is based on the determined conflict in a shared computing resource circuit (s) 228 based on the system status indicators 302 (1) -302 (3) , platform status indicators 304 (1) -304 (3) , and application status indicators 306 (1) -306 (2) . For example, the arbitration module 508 in this example has access to issue requests 517 to an OS scheduler 518 in the CPU 104 to control the scheduling, priority (e.g., modulation) , and / or execution (e.g., termination) of the AVP application 206 and / or the DP application 208 of the DAS 204 based on the determined execution behavior of the AVP application 206 and / or the DP application 208 of the DAS 204 to try to resolve the shared resource conflict. The arbitration module 508 can include the application modulation rules 312, schedule rules 314, and system level strategy rules 316 in the supervision system 530 like  provided in the supervision system 230 in Figure 3, to determine the execution behavior of the AVP application 206 and / or the DP application 208 of the DAS 204 to try to resolve the shared resource conflict.

[0043] As shown in Figure 5, the AVP monitoring component 504 is coupled to an AVP application programming interface (API) 520 of the AVP application 206 as a control point to the AVP application 206 to be able to modulate its behavior (e.g., disable certain functionalities) in response to a request 522 (1) by the arbitration module 508 to modulate the AVP application 206. The DP monitoring component 506 is coupled a DP API 524 of the DP application 208 as a control point to the DP application 208 to be able to modulate its behavior (e.g., disable certain functionalities) in response to a request 522 (2) by the arbitration module 508 to modulate the DP application 208. The arbitration module 508 can also issue a request 522 (3) to the computing resource manager 509 to schedule the shared processors 106-114 as part of arbitrating the execution behavior of the AVP application 206 and / or DP application 208. The arbitration module 508 can also issue a request 522 (4) to the sysprofiler 510 to control the interface with the power management circuit 152 indicating the platform loading, temperature from the thermal sensors 148, memory system 120, and connectivity system 136 as examples as part of arbitrating the execution behavior of the AVP application 206 and / or DP application 208. The arbitration module 508 can also issue a request 522 (5) to the power management component 512 to control the interface with the power management circuit 152 to change the power mode of the SoC 202 as part of arbitrating the execution behavior of the AVP application 206 and / or DP application 208. The arbitration module 508 can also issue a request 522 (6) to the network QoS component 514 to control the memory bandwidth of the system memory 132 as part of arbitrating the execution behavior of the AVP application 206 and / or DP application 208.

[0044] Note that although the supervision system 530 in Figure 5 is shown as arbitrating the execution behavior of the AVP application 206 and DP application 208 in the DAS 204 as part of a VM, such as the VM 203 (1) in Figure 2, the supervision system 530 is also configured to arbitrate the execution behavior of the other applications in other VMs not shown, such as the applications 205 in the other VMs 203 (2) -203 (X) in Figure 2.

[0045] Figure 6 is a block diagram of the supervision system 530 in Figure 5 configured as a host supervision system 530 and a separate guest supervision system 630 that can be supported in the SoCs 102, 202 in Figures 1 and 2. In this example, as discussed in Figure 5, the host supervision system 530 and guest supervision system 630 are configured to be executed by the CPU 104 in the SoC 202 as an example, which is referenced as including the components in the SoC 102 in Figure 1. The host supervision system 530 is responsible for arbitrating the execution of the AVP application 206 and DP application 208 as part of the DAS 204 in this example. As discussed below, the guest supervision system 630 is responsible for arbitrating the execution of the IVI applications 214-220 for the IVI system 212 in this example. In this manner, the host supervision system 530 and guest supervision system 630 can be configured to operate separately to perform supervision of the DAS applications 206, 208 of the DAS 204 and the IVI applications 214-220 of the IVI system 212, if desired. However, in this example, the host supervision system 530 is responsible for receiving the system status indicators 302 (1) -302 (3) and platform status indicators 304 (1) -304 (3) and instructing the guest supervision system 630 on the available resources to use to decide how to arbitrate the execution of its IVI applications 214-220 to provide an end-to-end supervision system for the SoC 202 in Figure 2.

[0046] With reference to Figure 6, a socket 600 is provided to provide a communication path between the arbitration module 508 in the host supervision system 530 and a guest arbitration module 608 in the guest supervision system 630. Like the arbitration module 508 in Figure 5, the guest arbitration module 608 may also be a hardware circuit, a combination of hardware and software, and / or an application 205 executed by the CPU 104, such as in its OS or an OS of a VM 203. The guest arbitration module 608 is provided in the form of program code executed by the CPU 104. The guest arbitration module 608 is configured to receive application status indicators 306 (4) from an IVI monitoring component 604 of the IVI application (s) 214-220 indicating a status of the IVI application (s) 214-220 in the IVI system 212. These application status indicators 306 (4) can indicate fault information for the IVI application (s) 214-220. The guest arbitration module 608 may also be configured to receive a system status indicator 302 (4) from an alarm component 616 that may be a process or application indicating system alarms in the IVI system 212.

[0047] The guest arbitration module 608 is configured to determine a conflict in a shared computing resource circuit (s) 228 based on the application status indicators 306 (4) and system status indicators 302 (4) . The guest arbitration module 608 can then determine an execution behavior of the IVI application (s) 214-220 based on the determined conflict in a shared computing resource circuit (s) 228 based on the application status indicators 306 (4) and system status indicators 302 (4) , and based on at least one predefined rule for resolving the determined conflict. The guest arbitration module 608 can then arbitrate the execution behavior of the IVI application (s) 214-220 of the IVI system 212 based on the determined execution behavior of the IVI application (s) 214-220. For example, the guest arbitration module 608 in this example can control the scheduling, priority (e.g., modulation) , and / or execution (e.g., termination) of the IVI application (s) 214-220 of the IVI system 212 based on the determined execution behavior of the IVI application (s) 214-220 to try to resolve the shared resource conflict. The guest arbitration module 608 can include the application modulation rules 312, schedule rules 314, and system level strategy rules 316 in the guest supervision system 630 like provided in the supervision system 230 in Figure 3, to determine the execution behavior of the IVI application (s) 214-220 of the IVI system 212 to try to resolve the shared resource conflict. The IVI monitoring component 604 can be coupled an IVI API as a control point to the IVI application (s) 214-220 to be able to modulate its behavior (e.g., disable certain functionalities) in response to a request 522 (7) by the guest arbitration module 608 to modulate the IVI application (s) 214-220.

[0048] In this example, the guest arbitration module 608 in the guest supervision system 630 is also configured to communicate over the socket 600 with the arbitration module 508 in the host supervision system 530. The arbitration module 508 in the host supervision system 530 can obtain loading information on the CPU 104 from execution of the IVI applications 214-220 of the IVI system 212 and arbitrate the execution of the DAS application (s) 206, 208 in the DAS 204 in response. The arbitration module 508 in the host supervision system 530 can also instruct the guest arbitration module 608 in the guest supervision system 630 to arbitrate the execution behavior of the IVI application (s) 214-220 to try to resolve the shared resource conflict in shared computing resource circuit (s) 228 determined by the guest supervision system 630.

[0049] Note that although the host and guest supervision systems 530, 630 in Figure 6 are shown as arbitrating the execution behavior of the respective DAS 204 and IVI system 212 as part of a VM, such as the VM 203 (1) in Figure 2, the host and guest supervision systems 530, 630 can also configured to arbitrate the execution behavior of the other applications in other VMs not shown, such as the applications 205 in the other VMs 203 (2) -203 (X) in Figure 2.

[0050] A processor-based system included in a SoC, wherein the SoC can support multiple VMs executed under control of hypervisor, and wherein the SoC supports a supervision system (s) , including, but not limited to, the supervision systems 230, 530, 630 in Figures 2-3 and 5-6, configured to arbitrate the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC, and that supports a process arbitrating the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources according to, but not limited to, the process 400 in Figure 4; and according to any aspects disclosed herein, may be provided in or integrated into any processor-based device. Examples, without limitation, include a set top box, an entertainment unit, a navigation device, a communications device, a fixed location data unit, a mobile location data unit, a global positioning system (GPS) device, a mobile phone, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a tablet, a phablet, a server, a computer, a portable computer, a mobile computing device, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc. ) , a desktop computer, a personal digital assistant (PDA) , a monitor, a computer monitor, a television, a tuner, a radio, a satellite radio, a music player, a digital music player, a portable music player, a digital video player, a video player, a digital video disc (DVD) player, a portable digital video player, an automobile, a vehicle component, an avionics system, a drone, and a multicopter.

[0051] In this regard, Figure 7 illustrates an example of a processor-based system 700 included in a SoC 702, wherein the SoC 702 can support multiple VMs executed under control of a hypervisor, and wherein the SoC supports a supervision system (s) 704, 704 (1) including, but not limited to, the supervision systems 230, 530, 630 in Figures 2-3 and 5-6, configured to arbitrate the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing  resources in the SoC, and that supports a process arbitrating the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources according to, but not limited to, the process 400 in Figure 4, and according to any aspects disclosed herein. In this example, the processor-based system 700 may be formed as an IC 706. The processor-based system 700 includes a processing unit (PU) 708 that includes one or more processors 710, which can include a central processing unit (CPU) , graphics processing unit (GPU) , and neural processing unit (NPU) . The supervision system 704 (1) can be provided to be executed as part of an OS or VM in the PU 708. The PU 708 may have a shared cache memory 712 coupled to the PU 708 for rapid access to temporarily stored data.

[0052] The processors 710 are coupled to a system bus 714 and can intercouple master and slave devices included in the processor-based system 700. As is well known, the processors 710 communicate with these other devices by exchanging address, control, and data information over the system bus 714. For example, the processors 710 can communicate bus transaction requests to a memory controller 716, as an example of a slave device. Although not illustrated in Figure 7, multiple system buses 714 could be provided, wherein each system bus 714 constitutes a different fabric. Other master and slave devices can be connected to the system bus 714. As illustrated in Figure 7, these devices can include a memory system 720 that includes the memory controller 716 and a memory array (s) 718.

[0053] With continuing reference to Figure 7, the processor-based system 700 also includes one or more input devices 722, one or more output devices 724, one or more network interface devices 726, and one or more display controllers 728 as examples. The input device (s) 722 can include any type of input device, including, but not limited to, input keys, switches, voice processors, etc. The output device (s) 724 can include any type of output device, including, but not limited to, audio, video, other visual indicators, etc. The network interface device (s) 726 can be any device configured to allow exchange of data to and from a network 730. The network 730 can be any type of network, including, but not limited to, a wired or wireless network, a private or public network, a local area network (LAN) , a wireless local area network (WLAN) , a wide area network (WAN) , a BLUETOOTHTM network, and the Internet. The network interface device (s) 730 can be configured to support any type of communications protocol desired.

[0054] The processors 710 may also be configured to access the display controller (s) 728 over the system bus 714 to control information sent to one or more displays 732. The display controller (s) 728 sends information to the display (s) 732 to be displayed via one or more video processors 734, which process the information to be displayed into a format suitable for the display (s) 732. The display controller (s) 728 and video processor (s) 734 can be included in the same or different ICs, or in the same IC 706 containing the PU 708, as examples. The display (s) 732 can include any type of display, including, but not limited to, a cathode ray tube (CRT) , a liquid crystal display (LCD) , a plasma display, a light emitting diode (LED) display, etc.

[0055] Figure 8 illustrates an exemplary wireless communications device 800 that includes radio frequency (RF) components and that can include a processor-based system 802, 802 (1) , 802 (2) that can be included in a respective SoC 803, 803 (1) , 803 (2) , wherein the SoC 803, 803 (1) , 803 (2) can support multiple VMs executed under control of a hypervisor, and wherein the SoC supports a supervision system (s) including, but not limited to, the supervision systems 230, 530, 630 in Figures 2-3 and 5-6, configured to arbitrate the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources in the SoC, and that supports a process arbitrating the execution behavior of applications executed by the VMs based on monitored status indicators in the SoC to resolve conflicts to shared computing resources according to, but not limited to, the process 400 in Figure 4, and according to any aspects disclosed herein. The wireless communications device 800 may include or be provided in any of the above-referenced devices, as examples.

[0056] As shown in Figure 8, the wireless communications device 800 includes a transceiver 804 and a data processor 806, each of which may include its processor-based system 802 (1) , 802 (2) in a respective SoC 803 (1) , 803 (2) . The transceiver 804 includes a transmitter 808 and a receiver 810 that support bi-directional communications. In general, the wireless communications device 800 may include any number of transmitters 808 and / or receivers 810 for any number of communication systems and frequency bands. All or a portion of the transceiver 804 may be implemented on one or more analog ICs, RF ICs (RFICs) , mixed-signal ICs, etc.

[0057] The transmitter 808 or the receiver 810 may be implemented with a super-heterodyne architecture or a direct-conversion architecture. In the super-heterodyne  architecture, a signal is frequency-converted between RF and baseband in multiple stages, e.g., from RF to an intermediate frequency (IF) in one stage, and then from IF to baseband in another stage for the receiver 810. In the direct-conversion architecture, a signal is frequency-converted between RF and baseband in one stage. The super-heterodyne and direct-conversion architectures may use different circuit blocks and / or have different requirements. In the wireless communications device 800 in Figure 8, the transmitter 808 and the receiver 810 are implemented with the direct-conversion architecture.

[0058] In the transmit path, the data processor 806 processes data to be transmitted and provides I and Q analog output signals to the transmitter 808. In the exemplary wireless communications device 800, the data processor 806 includes digital-to-analog converters (DACs) 812 (1) , 812 (2) for converting digital signals generated by the data processor 806 into the I and Q analog output signals, e.g., I and Q output currents, for further processing.

[0059] Within the transmitter 808, lowpass filters 814 (1) , 814 (2) filter the I and Q analog output signals, respectively, to remove undesired signals caused by the prior digital-to-analog conversion. Amplifiers (AMPs) 816 (1) , 816 (2) amplify the signals from the lowpass filters 814 (1) , 814 (2) , respectively, and provide I and Q baseband signals. An upconverter 818 upconverts the I and Q baseband signals with I and Q transmit (TX) local oscillator (LO) signals through mixers 820 (1) , 820 (2) from a TX LO signal generator 822 to provide an upconverted signal 824. A filter 826 filters the upconverted signal 824 to remove undesired signals caused by the frequency up-conversion as well as noise in a receive frequency band. A power amplifier (PA) 828 amplifies the upconverted signal 824 from the filter 826 to obtain the desired output power level and provides a transmit RF signal. The transmit RF signal is routed through a duplexer or switch 830 and transmitted via an antenna 832.

[0060] In the receive path, the antenna 832 receives signals transmitted by base stations and provides a received RF signal, which is routed through the duplexer or switch 830 and provided to a low noise amplifier (LNA) 834. The duplexer or switch 830 is designed to operate with a specific receive (RX) -to-TX duplexer frequency separation, such that RX signals are isolated from TX signals. The received RF signal is amplified by the LNA 834 and filtered by a filter 836 to obtain a desired RF input signal. Down-conversion mixers 838 (1) , 838 (2) mix the output of the filter 836 with I and Q RX LO  signals (i.e., LO_I and LO_Q) from an RX LO signal generator 840 to generate I and Q baseband signals. The I and Q baseband signals are amplified by AMPs 842 (1) , 842 (2) and further filtered by lowpass filters 844 (1) , 844 (2) to obtain I and Q analog input signals, which are provided to the data processor 806. In this example, the data processor 806 includes analog-to-digital converters (ADCs) 846 (1) , 846 (2) for converting the analog input signals into digital signals to be further processed by the data processor 806.

[0061] In the wireless communications device 800 of Figure 8, the TX LO signal generator 822 generates the I and Q TX LO signals used for frequency up-conversion, while the RX LO signal generator 840 generates the I and Q RX LO signals used for frequency down-conversion. Each LO signal is a periodic signal with a particular fundamental frequency. A TX phase-locked loop (PLL) circuit 848 receives timing information from the data processor 806 and generates a control signal used to adjust the frequency and / or phase of the TX LO signals from the TX LO signal generator 822. Similarly, an RX PLL circuit 850 receives timing information from the data processor 806 and generates a control signal used to adjust the frequency and / or phase of the RX LO signals from the RX LO signal generator 840.

[0062] Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the aspects disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer readable medium and executed by a processor or other processing device or processing unit, or combinations of both. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends upon the particular application, design choices, and / or design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0063] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a processor, a Digital Signal Processor (DSP) , an Application Specific Integrated Circuit  (ASIC) , a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration) .

[0064] The aspects disclosed herein may be embodied in hardware and in instructions that are stored in hardware, and may reside, for example, in Random Access Memory (RAM) , flash memory, Read Only Memory (ROM) , Electrically Programmable ROM (EPROM) , Electrically Erasable Programmable ROM (EEPROM) , registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer readable medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a remote station. In the alternative, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.

[0065] It is also noted that the operational steps described in any of the exemplary aspects herein are described to provide examples and discussion. The operations described may be performed in numerous different sequences other than the illustrated sequences. Furthermore, operations described in a single operational step may actually be performed in a number of different steps. Additionally, one or more operational steps discussed in the exemplary aspects may be combined. It is to be understood that the operational steps illustrated in the flowchart diagrams may be subject to numerous different modifications as will be readily apparent to one of skill in the art. Those of skill in the art will also understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents,  electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0066] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0067] Implementation examples are described in the following numbered clauses:

[0068] 1. A system-on-a-chip (SoC) , comprising:

[0069] one or more shared computing resource circuits;

[0070] a central processing unit (CPU) configured to execute a hypervisor to schedule execution of a plurality of virtual machines (VMs) comprising a plurality of applications to be executed,

[0071] the CPU configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed; and

[0072] a supervision system, comprising:

[0073] a monitoring module configured to:

[0074] receive one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits; and

[0075] receive one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits; and

[0076] an arbitration module configured to:

[0077] determine a conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators;

[0078] determine an execution behavior of at least one application of the plurality of applications to resolve the determined conflict; and

[0079] arbitrate the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0080] 2. The SoC of clause 1, wherein:

[0081] the one or more shared computing resource circuits comprise a memory system;

[0082] the CPU is configured to execute the plurality of applications to cause each to access the memory system; and

[0083] the arbitration module is configured to determine the conflict by being configured to determine a memory conflict resulting from the execution of the plurality of applications each accessing the memory system, based on the one or more platform status indicators and the one or more application status indicators.

[0084] 3. The SoC of clause 2, wherein the arbitration module is configured to determine the memory conflict based on a first application status indicator of the one or more application status indicators associated with a first application among the plurality of applications generating an error code indicating insufficient memory being available for the first application in the memory system.

[0085] 4. The SoC of clause 3, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of the first application to resolve the determined conflict.

[0086] 5. The SoC of clause 3, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of a second application of the plurality of applications to resolve the determined conflict.

[0087] 6. The SoC of any of clauses 3-5, wherein the arbitration module is further configured to determine one or more second applications among the plurality of applications consuming memory in the memory system that cause the error code indicating the insufficient memory for the first application based on the one or more platform status indicators indicating memory consumption in the memory system by the respective one or more second applications.

[0088] 7. The SoC of clause 6, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of at least one second application of the one or more second applications to resolve the determined memory conflict.

[0089] 8. The SoC of clause 1, wherein:

[0090] the one or more shared computing resource circuits comprise a context stack in the CPU;

[0091] the CPU is configured to execute the plurality of applications to cause a plurality of contexts for each VM of the plurality of VMs to be switched into the CPU; and

[0092] the arbitration module is configured to determine the conflict by being configured to determine a context loading conflict resulting from the execution of the plurality of applications, based on the one or more platform status indicators indicating a context loading error for a first VM of the plurality of VMs.

[0093] 9. The SoC of clause 8, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of the first VM to resolve the determined context loading conflict.

[0094] 10. The SoC of clause 8, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of at least one second VM of the plurality of VMs to resolve the determined context loading conflict.

[0095] 11. The SoC of any of clauses 1-10, wherein:

[0096] the monitoring module is further configured to receive one or more system status indicators each indicating a status of the SoC; and

[0097] the arbitration module is configured to determine the conflict in the one or more shared computing resource circuits by being configured to:

[0098] determine the conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more system status indicators, the one or more platform status indicators, and the one or more application status indicators.

[0099] 12. The SoC of clause 11, wherein the arbitration module is configured to determine the conflict by being configured to determine an excessive temperature conflict resulting from the execution of the plurality of applications, based on the one or more system status indicators indicating an excessive temperature in the SoC.

[0100] 13. The SoC of clause 12, wherein the arbitration module is further configured to change a power mode of the SoC to a lower power mode in response to determining the excessive temperature conflict.

[0101] 14. The SoC of any of clauses 1-13, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to terminate the execution of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0102] 15. The SoC of any of clauses 1-14, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to modulate an execution speed of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0103] 16. The SoC of any of clauses 1-15, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to  change a scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0104] 17. The SoC of clause 16, wherein the arbitration module is configured to change the scheduling priority of the at least one application by being configured to lower the scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0105] 18. The SoC of clause 16, wherein the arbitration module is configured to change the scheduling priority of the at least one application by being configured to increase the scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0106] 19. The SoC of any of clauses 1-18, wherein:

[0107] the plurality of VMs comprises:

[0108] a host VM comprising the plurality of applications; and

[0109] a guest VM comprising a plurality of guest applications;

[0110] the CPU is configured to execute the hypervisor to schedule execution of the host VM and the guest VM,

[0111] the CPU further configured to execute the plurality of guest applications to cause the one or more shared computing resource circuits to be accessed; and

[0112] the SoC further comprising:

[0113] a guest supervision system, comprising:

[0114] a guest monitoring module configured to:

[0115] receive one or more guest application status indicators each indicating a status of an access by a guest application of the plurality of guest applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits;

[0116] the supervision system further configured to:

[0117] communicate a guest system execution behavior request to the guest supervision system based on the determined execution behavior of the at least one application; and

[0118] the guest supervision system further comprising:

[0119] a guest arbitration module configured to:

[0120] determine a guest conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of guest applications, based on the one or more platform status indicators, the one or more guest application status indicators, and the guest system execution behavior request;

[0121] determine a guest execution behavior of at least one guest application of the plurality of guest applications to resolve the determined guest conflict; and

[0122] arbitrate the guest execution behavior of the at least one guest application of the plurality of guest applications based on the determined guest execution behavior of the at least one guest application.

[0123] 20. The SoC of any of clauses 1-19, wherein a first VM of the plurality of VMs comprises one or more driver assistance system (DAS) applications in the plurality of applications.

[0124] 21. The SoC of clause 20, wherein the one or more DAS applications comprise one or more of an automotive vision perception application, a drive policy application, and a viewing parking application.

[0125] 22. The SoC of clause 20 or 21, wherein a second VM of the plurality of VMs comprises one or more in-vehicle infotainment (IVI) applications in the plurality of applications.

[0126] 23. The SoC of clause 22, wherein the one or more IVI applications comprise one or more of a driver monitoring system application, a display application, an audio application, and a cloud storage interface application.

[0127] 24. The SoC of clause 22 or 23, wherein the first VM and the second VM comprise the same VM.

[0128] 25. The SoC of any of clauses 1-24, wherein the one or more shared computing resource circuits are selected from the group consisting of a cache memory, a system memory, a media processor, a vector processing unit (VPU) , a graphics processing unit (GPU) , and an interface circuit.

[0129] 26. The SoC of any of clauses 1-25 integrated into a device selected from the group consisting of: a set top box; an entertainment unit; a navigation device; a communications device; a fixed location data unit; a mobile location data unit; a global positioning system (GPS) device; a mobile phone; a cellular phone; a smart phone; a session initiation protocol (SIP) phone; a tablet; a phablet; a server; a computer; a portable computer; a mobile computing device; a wearable computing device; a desktop computer; a personal digital assistant (PDA) ; a monitor; a computer monitor; a television; a tuner; a radio; a satellite radio; a music player; a digital music player; a portable music player; a digital video player; a video player; a digital video disc (DVD) player; a portable digital video player; an automobile; a vehicle component; avionics systems; a drone; and a multicopter.

[0130] 27. A method of controlling execution behavior of applications of virtual machines (VMs) executed in a system-on-a-chip (SoC) , the SoC comprising:

[0131] one or more shared computing resource circuits;

[0132] a central processing unit (CPU) configured to execute a hypervisor to schedule execution of a plurality of VMs comprising a plurality of applications to be executed,

[0133] the CPU configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed; and

[0134] the method comprising:

[0135] receiving one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits; and

[0136] receiving one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits; and

[0137] determining a conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators;

[0138] determining an execution behavior of at least one application of the plurality of applications to resolve the determined conflict; and

[0139] arbitrating the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0140] 28. The method of clause 27, wherein arbitrating the execution behavior of the at least one application comprises terminating the execution of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0141] 29. The method of clause 27 or 28, wherein arbitrating the execution behavior of the at least one application comprises modulating an execution speed of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0142] 30. The method of any of clauses 27-29, wherein arbitrating the execution behavior of the at least one application comprises changing a scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.

[0143] 31. The method of any of clauses 27-30, wherein:

[0144] the plurality of VMs comprises:

[0145] a host VM comprising the plurality of applications; and

[0146] a guest VM comprising a plurality of guest applications; and

[0147] the CPU is configured to execute the hypervisor to schedule execution of the host VM and the guest VM,

[0148] the CPU further configured to execute the plurality of guest applications to cause the one or more shared computing resource circuits to be accessed; and

[0149] the method further comprising:

[0150] receiving one or more guest application status indicators each indicating a status of an access by a guest application of the plurality of guest applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits;

[0151] communicating a guest system execution behavior request to a guest supervision system based on the determined execution behavior of the at least one application;

[0152] determining a guest conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of guest applications, based on the one or more platform status indicators, the one or more guest application status indicators, and the guest system execution behavior request;

[0153] determining a guest execution behavior of at least one guest application of the plurality of guest applications to resolve the determined guest conflict; and

[0154] arbitrating the guest execution behavior of the at least one guest application of the plurality of guest applications based on the determined guest execution behavior of the at least one guest application.

Claims

A system-on-a-chip (SoC) , comprising:one or more shared computing resource circuits;a central processing unit (CPU) configured to execute a hypervisor to schedule execution of a plurality of virtual machines (VMs) comprising a plurality of applications to be executed,the CPU configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed; anda supervision system, comprising:a monitoring module configured to:receive one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits; andreceive one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits; andan arbitration module configured to:determine a conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators;determine an execution behavior of at least one application of the plurality of applications to resolve the determined conflict; andarbitrate the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 1, wherein:the one or more shared computing resource circuits comprise a memory system;the CPU is configured to execute the plurality of applications to cause each to access the memory system; andthe arbitration module is configured to determine the conflict by being configured to determine a memory conflict resulting from the execution of the plurality of applications each accessing the memory system, based on the one or more platform status indicators and the one or more application status indicators.The SoC of claim 2, wherein the arbitration module is configured to determine the memory conflict based on a first application status indicator of the one or more application status indicators associated with a first application among the plurality of applications generating an error code indicating insufficient memory being available for the first application in the memory system.The SoC of claim 3, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of the first application to resolve the determined conflict.The SoC of claim 3, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of a second application of the plurality of applications to resolve the determined conflict.The SoC of claim 3, wherein the arbitration module is further configured to determine one or more second applications among the plurality of applications consuming memory in the memory system that cause the error code indicating the insufficient memory for the first application based on the one or more platform status indicators indicating memory consumption in the memory system by the respective one or more second applications.The SoC of claim 6, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of at least one second application of the one or more second applications to resolve the determined memory conflict.The SoC of claim 1, wherein:the one or more shared computing resource circuits comprise a context stack in the CPU;the CPU is configured to execute the plurality of applications to cause a plurality of contexts for each VM of the plurality of VMs to be switched into the CPU; andthe arbitration module is configured to determine the conflict by being configured to determine a context loading conflict resulting from the execution of the plurality of applications, based on the one or more platform status indicators indicating a context loading error for a first VM of the plurality of VMs.The SoC of claim 8, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of the first VM to resolve the determined context loading conflict.The SoC of claim 8, wherein the arbitration module is configured to determine the execution behavior of the at least one application by being configured to determine the execution behavior of at least one second VM of the plurality of VMs to resolve the determined context loading conflict.The SoC of claim 1, wherein:the monitoring module is further configured to receive one or more system status indicators each indicating a status of the SoC; andthe arbitration module is configured to determine the conflict in the one or more shared computing resource circuits by being configured to:determine the conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more system status indicators, the one or more platform status indicators, and the one or more application status indicators.The SoC of claim 11, wherein the arbitration module is configured to determine the conflict by being configured to determine an excessive temperature conflict resulting from the execution of the plurality of applications, based on the one or more system status indicators indicating an excessive temperature in the SoC.The SoC of claim 12, wherein the arbitration module is further configured to change a power mode of the SoC to a lower power mode in response to determining the excessive temperature conflict.The SoC of claim 1, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to terminate the execution of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 1, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to modulate an execution speed of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 1, wherein the arbitration module is configured to arbitrate the execution behavior of the at least one application by being configured to change a scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 16, wherein the arbitration module is configured to change the scheduling priority of the at least one application by being configured to lower the scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 16, wherein the arbitration module is configured to change the scheduling priority of the at least one application by being configured to increase the scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The SoC of claim 1, wherein:the plurality of VMs comprises:a host VM comprising the plurality of applications; anda guest VM comprising a plurality of guest applications;the CPU is configured to execute the hypervisor to schedule execution of the host VM and the guest VM,the CPU further configured to execute the plurality of guest applications to cause the one or more shared computing resource circuits to be accessed; andthe SoC further comprising:a guest supervision system, comprising:a guest monitoring module configured to:receive one or more guest application status indicators each indicating a status of an access by a guest application of the plurality of guest applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits;the supervision system further configured to:communicate a guest system execution behavior request to the guest supervision system based on the determined execution behavior of the at least one application; andthe guest supervision system further comprising:a guest arbitration module configured to:determine a guest conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of guest applications, based on the one or more platform status indicators, the one or more guest application status indicators, and the guest system execution behavior request;determine a guest execution behavior of at least one guest application of the plurality of guest applications to resolve the determined guest conflict; andarbitrate the guest execution behavior of the at least one guest application of the plurality of guest applications based on the determined guest execution behavior of the at least one guest application.The SoC of claim 1, wherein a first VM of the plurality of VMs comprises one or more driver assistance system (DAS) applications in the plurality of applications.The SoC of claim 20, wherein the one or more DAS applications comprise one or more of an automotive vision perception application, a drive policy application, and a viewing parking application.The SoC of claim 20, wherein a second VM of the plurality of VMs comprises one or more in-vehicle infotainment (IVI) applications in the plurality of applications.The SoC of claim 22, wherein the one or more IVI applications comprise one or more of a driver monitoring system application, a display application, an audio application, and a cloud storage interface application.The SoC of claim 22, wherein the first VM and the second VM comprise the same VM.The SoC of claim 1, wherein the one or more shared computing resource circuits are selected from the group consisting of a cache memory, a system memory, a media processor, a vector processing unit (VPU) , a graphics processing unit (GPU) , and an interface circuit.The SoC of claim 1 integrated into a device selected from the group consisting of: a set top box; an entertainment unit; a navigation device; a communications device; a fixed location data unit; a mobile location data unit; a global positioning system (GPS) device; a mobile phone; a cellular phone; a smart phone; a session initiation protocol (SIP) phone; a tablet; a phablet; a server; a computer; a portable computer; a mobile computing device; a wearable computing device; a desktop computer; a personal digital assistant (PDA) ; a monitor; a computer monitor; a television; a tuner; a radio; a satellite radio; a music player; a digital music player; a portable music player; a digital video player; a video player; a digital video disc (DVD) player; a portable digital video player; an automobile; a vehicle component; avionics systems; a drone; and a multicopter.A method of controlling execution behavior of applications of virtual machines (VMs) executed in a system-on-a-chip (SoC) , the SoC comprising:one or more shared computing resource circuits;a central processing unit (CPU) configured to execute a hypervisor to schedule execution of a plurality of VMs comprising a plurality of applications to be executed,the CPU configured to execute the plurality of applications to cause the one or more shared computing resource circuits to be accessed; andthe method comprising:receiving one or more platform status indicators each indicating an availability status of a shared computing resource circuit of the one or more shared computing resource circuits; andreceiving one or more application status indicators each indicating a status of an access by an application of the plurality of applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits; anddetermining a conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of applications, based on the one or more platform status indicators and the one or more application status indicators;determining an execution behavior of at least one application of the plurality of applications to resolve the determined conflict; andarbitrating the execution behavior of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The method of claim 27, wherein arbitrating the execution behavior of the at least one application comprises terminating the execution of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The method of claim 27, wherein arbitrating the execution behavior of the at least one application comprises modulating an execution speed of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The method of claim 27, wherein arbitrating the execution behavior of the at least one application comprises changing a scheduling priority of the at least one application of the plurality of applications based on the determined execution behavior of the at least one application.The method of claim 27, wherein:the plurality of VMs comprises:a host VM comprising the plurality of applications; anda guest VM comprising a plurality of guest applications; andthe CPU is configured to execute the hypervisor to schedule execution of the host VM and the guest VM,the CPU further configured to execute the plurality of guest applications to cause the one or more shared computing resource circuits to be accessed; andthe method further comprising:receiving one or more guest application status indicators each indicating a status of an access by a guest application of the plurality of guest applications executed by the CPU, to a shared computing resource circuit of the one or more shared computing resource circuits;communicating a guest system execution behavior request to a guest supervision system based on the determined execution behavior of the at least one application;determining a guest conflict in the one or more shared computing resource circuits resulting from the execution of the plurality of guest applications, based on the one or more platform status indicators, the one or more guest application status indicators, and the guest system execution behavior request;determining a guest execution behavior of at least one guest application of the plurality of guest applications to resolve the determined guest conflict; andarbitrating the guest execution behavior of the at least one guest application of the plurality of guest applications based on the determined guest execution behavior of the at least one guest application.

Images