@slp You mentioned at the beginning of the post that you're working on virtualization for RHIVOS. I'm curious about why an in-vehicle OS needs virtualization. Can you share anything publicly about that yet?
@matt Sure. There are various use cases, but the main one by far is running Android Automotive OS on the same system.
This saves you from having to put a second computer on your car just for running AAOS, and from dealing with the all the hardware enablement pain for another OS.
The wider goal, shared with Linaro and other players, is for virtio to become the standard set of interfaces for doing VM integrations in an Automotive environment.
@slp What about running AAOS in a container (i.e. using a cgroup and namespaces)? Is it still necessary to run a heavily patched kernel to run the Android stack? I know that some Android kernel bits, like the binder, got mainlined.
@matt Running any Android on a container is opening a can of worms. It may work today, but who knows if it'll work after the next update. Even Google have move away from running Android as a container in ChromeOS, using now a crosvm-based VM.
A VM gives you a stable and well-known contact surface based on a minimal amount of emulated system devices and standard virtio devices.
@matt You can use virtio-balloon’s free page reporting to return pages to the host, and DAX to avoid relying on the guest’s filesystem cache, effectively reducing the footprint to the bare minimum.
But I doubt Automotive deployments will rely on any of that since in most cases they’ll probably prefer predictable, static resource allocations for both latency and safety reasons.
Add comment