back to article Automotive Grade Linux shops for hypervisor to accelerate smart cars

The Automotive Grade Linux is shopping for a hypervisor so that in-car computers can handle lots of different jobs. The effort has previously delivered an infotainment platform that Toyota has adopted. That platform has now landed as the Automotive Grade Linux Unified Code Base (AGL UCB) 4.0, which the Linux Foundation happily …


A hypervisor to do what?

Accelerate? A hypervisor? As in a particular hypervisor that will make an OS that is running as a guest go faster than it would if it were running on bare metal?

That sounds great, but there is just one problem: Hypervisors let computer do more of everything at once all of it more slowly. If there will ever be a virtualization technology that is faster than bare metal it will only exist in the marketing department. Anything else would kind of violate the Laws of Thermodynamics. But only just a little bit.

So let's drop the marketing spin the headlines and have more of "Automotive Grade Linux Breaks for Virtual Machines."

Simon Sharwood, Reg APAC Editor (Written by Reg staff)

Re: A hypervisor to do what?

Well you have a point about VM speed, but the acceleration I alluded to is in the development of smart cars through allowing them to have one CPU rather than lots.

DrXym Silver badge

Re: A hypervisor to do what?

A hypervisor in a car would serve the same purpose as a hypervisor in a games console - it allows code to run in its own little box with little or no access to code running with a higher privilege or in a different box. So that even if someone managed somehow to hack / root the infotainment system, it wouldn't provide them with access to other critical systems in the vehicle.

Given the number of stories about remotely hacked vehicles and the increasing use of over the air updates, phone apps etc., this would seem like a sensible thing to add.

That said, I could see how even hacking the infotainment system could screw with a car. Most systems would have control to functions like door / boot locks, fuel cap release, air conditioning, volume controls, bluetooth, gps etc. then there are still opportunities to grief the car, remotely open it, listen to conversations, track its location etc.

Matt Bryant Silver badge

Re: Simon Re: A hypervisor to do what?

"....the development of smart cars through allowing them to have one CPU rather than lots." Which in itself is a BAD IDEA as the manufacturers will use the excuse to run vital control apps on the same hypervisor as infotainment apps! The aircraft industry has it right - keep control apps/signals on their own separate CPUs/buses.

frank ly Silver badge

Why not use 'containers'?

Just asking.

Trevor_Pott Gold badge

Re: Why not use 'containers'?

Containers = multiple apps, single OSE

VMs = multiple apps, multiple OSEs

In car IT, there are a lot of very specific differences between OSEs for the different apps.


Well that's my local friendly garage scr*wed then

John Mangan

I have a concern that...

car product development cycles are long whereas software development cycles (and even the hardware it runs on) are very short.

If security is really going to be a priority then there needs to be some way to ensure that devices that can be on the roads for twenty years or more will still get regular security updates for their full lifespan.

That is nothing but an overhead for the manufacturers but the thought of millions of (effectively) 'Windows 95' vehicles still being on the road in the 'Windows 10' era is not comforting from a security point of view.

This, to me, seems a strong reason for fully autonomous vehicles available on demand (cycled regularly by the manufacturers) to replace individual vehicle ownership.

handleoclast Silver badge

Allow me to interrupt

It is not just the case, as chuckufarley pointed out, that VMs mean that OSs run slower than they would if running on bare metal, there are interrupts to consider.

I once saw somebody attempt to run a telephony product (think Asterisk or FreeSwitch) on a VM. It was on a new, beefy box that was as yet unused (but, of course, there were big plans for it). I had my doubts when the idea was proposed, because of interrupt handling. Neither Linux nor Windows are real-time OSs, and that they can perform almost as well as an RTOS is down to the fast hardware we have these days. But the interrupt handling of a host running on a hypervisor is a little unpredictable.

Yes, interrupts are (by their nature) unpredictable as to when they happen. The handling of them is a bit variable as to timing. Also unpredictable is how many different interrupts happen while another interrupt is being processed, and in what order those pending interrupts are processed. But things get a lot worse in a hypervisor that is running several hosts.

Long story short, the result sounded like a Dalek gargling down a drainpipe. The telephony product was then shifted onto an older box running web and mail services (don't ask about the security implications of that), and fairly heavily loaded, but it was running on bare metal. Much better. Occasional, infrequent, short-duration garbling, but not continuous garbling.

OK, this thing probably won't be shunting audio (and possibly video) around as byte streams being handled directly by the processor, so things will be less demanding. However, the idea of controlling tons of metal on an OS that isn't an RTOS, which is itself running on an OS that isn't an RTOS, is something I find a little scary. Yeah, I'll deal with the steering in a moment, right after I've sorted out the music and the request to lower the passenger window.

About the only thing I remember from digital control theory is that if you don't do it right then your system can be at the set-point at each measurement yet deviate wildly between measurements. Things only get worse if your measurement interval is not well-controlled because the hypervisor is busy handling interrupts from the music player.

YMMV, depending on whether or not your car hits a brick wall while lowering the passenger window.

Anonymous Coward
Anonymous Coward

Re: Allow me to interrupt

That's going to be down to Asterix . Freeswitch I'm afraid.

The big boys (Avaya / Mitel / Shortel) have been able to run in VM's for a long time.

DrXym Silver badge

Re: Allow me to interrupt

I doubt the hypervisor adds much impact to file, messaging or network IO compared to actual activity itself. Biggest impact would be on graphics. Graphics necessarily runs against the hardware so you either abstract and badly degrade the performance or you let the software use the hardware and pray that there are no exploits (unlikely) in the driver or the hardware itself.

Anonymous Coward
Anonymous Coward

Re: Allow me to interrupt

That'll be a bad configuration of Asterisk then (it is pretty complex), or poor hardware. I've had Asterisk running in a VM for ages, 1 vCPU, 2GB of RAM, 30GB of disk, it supports 50+ hard phones, ATA's, desktop softphones, mobile softphones, multiple outside trunks, and many 100's of calls a day, no problem at all...


Wrong solution

They've started from the viewpoint that Linux is the answer, and worked back from there. This is the wrong approach.

There are existing proven solutions for partitioned real time robust systems including support for duplication and migration of critical components. ARINC 653 springs to mind and can handle everything they want and a compatible RTOS is easy and cheap to buy in.

But no, let's shoehorn Linux into another space it isn't designed for. The hypervisor is just a cherry on top of their failure to understand the problem properly.

Anonymous Coward
Anonymous Coward

Re: Wrong solution

This reminds me of Independence Day, where the fictional aliens depicted in the movie were found to be susceptible to malware developed on human computers.

Well idiots, that is kind of what you can expect to happen when you shoehorn a desktop/server OS into a vehicle. FCA has been learning that lesson the hard way on those recent Jeep hacks.

Starace is absolutely right, and not just in terms of whether the OS will be efficient and reliable. Hackability is a major concern as well, and you can shrink the attack surface dramatically by starting with using an obscure OS. By instead using an OS that most IT professionals are familiar with, you can bet that the potential incoming hacks will be swift and devastating.

Warm Braw Silver badge

Re: Wrong solution

They've started from the viewpoint that Linux is the answer

I think they more likely started from the viewpoint that they wanted a free and established set of codecs and communications APIs, Not sure why they feel they need to provide an in-car "infotainment" system at all as it will almost certainly be obsolete long before the car is.

I recently acquired a car with built-in Bluetooth for the first time and it turns out my Android phone can'[t do navigation and stream audio at the same time. Well, it can, but the audio is unintelligible until you turn off navigation. And if the phone, running on top of Linux and having a processor which I imagine most cost-conscious car makers would consider over-specified, can't do real-time scheduling for audio streaming, what's the chance of putting all that on top of a hypervisor and expecting an improvement?

Anonymous Coward
Anonymous Coward

Re: Wrong solution

But no, let's shoehorn Linux into another space it isn't designed for. The hypervisor is just a cherry on top of their failure to understand the problem properly.

Because it's not been shoehorned into printers, CCTV cameras, phones, ATA's, WAPs, routers, firewalls, and lightbulbs is it?


Very bad plan

It is simple. The more code you put in something the more bugs it has. There are no exceptions to that rule.


There are proven products already on the market. Why reinvent??

Why are they reinventing the wheel? QNX is already a proven and security certified automotive platform with a hypervisor.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018