With the rapid adoption of automotive virtualization, manufacturers can now run multiple systems on a single computer, from highly reliable Linux software for mission-critical functions to highly customizable Android software for infotainment services. Although virtualization enables limitless opportunities to customize the driving experience, all these different virtual machines must still run their graphics processing requests through a single GPU.
In most vehicle architectures, the GPU is a separate co-processor with its own firmware. This means that each VM must send its commands and data to the GPU for processing and then receive the completed request from the GPU’s firmware. The problem with this setup is that if a VM sends an illegal command or bad data to the GPU and causes it to crash, no other VM can interact with the GPU until it is rebooted. Not only is this irritating, but it can affect the stability and security of any mission-critical vehicle software that is running on another VM.
Like everyone else, my company GlobalLogic struggled with a way to share a GPU between VMs without affecting the performance, stability, and security of those VMs. As part of our product development service offerings to automotive manufacturers, we utilize a virtualization platform called Nautilus to run multiple VMs on a single board computer. Although we had successfully sandboxed all automotive OSes leveraging a Xen Type 1 hypervisor, we were still dependent on the GPU hardware — and all its vulnerabilities.
Then we realized that instead of using the GPU’s firmware for all VMs, we should instead flip the script and build an architecture that enables each VM to work with its own GPU firmware. For example, if VM1 needs to process a graphics request, it will upload its firmware to the GPU, execute the necessary commands, and then “log off” from the GPU. Once VM1 is no longer using the GPU, VM2 can begin to upload its firmware — and so on and so forth.
Behind the scenes, the platform stores all states of the GPU in a virtual GPU driver that sits on the Xen hypervisor. When VM1 initiates a request to access the GPU, the platform resets the GPU and uploads the VM’s firmware so that the VM is working with the GPU from its last previous status. This reset-upload-execute-reset process enables each VM and GPU to work in a siloed session and not affect any other VM-GPU sessions. If VM1 sends an illegal command to the GPU, it will only crash its own specific session instead of the entire GPU. This approach greatly improves the stability and security of GPU-sharing in a virtualized environment.
Our GPU virtualization solution enables multiple domains to share the GPU hardware with no more than a 5 percent overall drop in performance. We are able to achieve this functionality by optimizing hardware resources across the native kernel module and carefully managing resources through a Xen mediator driver. With this architecture, no guest domain ever has access to any real hardware — everything is virtualized.
We have thoroughly tested this approach and integrated it into our Nautilus platform with fantastic results. We are currently using this architecture with live customers, and we will be further demonstrating the solution at the GENIVI showcase at CES 2016 if you’re interested in learning more about GPU virtualization.
As automotive manufacturers come to rely more on software to operate their vehicles and engage with drivers, the graphics capabilities of vehicle dashboard displays and IVI systems will become increasingly important. With GPU virtualization, manufacturers can optimize graphics processing performance across multiple VMs while also ensuring the stability and security of those VMs.
Alex Agizim is VP, CTO of Embedded Systems at GlobalLogic Inc.
Networking is set to be one of the biggest growth industries for open source software development this year, and a key part of that is Network Functions Virtualization (NFV). Set to transform the way networks are designed, NFV—an initiative to move to the cloud network services that have traditionally been carried out by proprietary, dedicated hardware—has seen explosive growth over the past few years, and that trajectory has only just begun. In fact, analyst firm Infonetics 
After being in development for over a year, the Kali Linux NetHunter 3.0 Android application has been released earlier today, January 6, 2016, by Offensive Security, the company behind 
The security-focused smartphone contained vulnerabilities which allow hackers to control the device’s modem and call functions.
Mention cloud, mention DevOps and it won’t be long before microservices enters the discussion. But what is, or are, microservices? The name implies something small – but what? Is it a part of a bigger thing or a piece of discrete functionality? And how are microservices different to application components? And why should we care?