AMD Improving Xen VirtIO GPU Support For In-Vehicle Infotainment, Using RADV

[QwertyChouskie]

It's even more than just "corporate stuff", it makes sense from an engineering perspective:

1. It's a microkernel by itself, a lot more compact than Linux (LoC isn't a perfect metric, but to give you an idea: 2% of Linux LoCs)
2. It also means it can be validated more easily (there's work on this aspect right now)
3. The security process around Xen is probably the best one in the world that I know in open source
4. Xen security design is really great (Grant tables and such, see https://xcp-ng.org/blog/2022/07/27/grant-table-in-xen/ ) vs the very thin isolation you can have with KVM+virtio
5. Xen Project is also very independent from big vendors, more you can imagine (no Google or RedHat might be in fact a plus…) even if you can find XenServer (ex-Citrix), AWS, Arm, Suse and others, it's pretty balanced for such a small code base
6. In automotive context, Xen can do static hardware partitioning, which is a VERY secure approach in terms of isolation. No "control VM" (Dom0, or control Domain) since Xen will know what hardware/resources to give access to which VM statically

Those are the reasons I have in mind right now

This level of robustness/security is very important to avoiding another 2015 Jeep Cherokee situation. (The only theoretically perfect solution is having drive systems and infotainment be entirely separate physical systems with 0 connection whatsoever, but given the current industry and consumer feature expectations, that's unlikely to happen.)

[olivier]

pretty exciting stuff for sure. any idea which bootable tools will be getting and exposing this work? I do the virtual machine documentation for blissOS which is AX86 and have been meaning to make some xen guides for a while (am somewhat familiar with xcp-ng). however the lack of general 3d acceleration without tools like sriov has made it fall pretty far down on the priority list (that and other factors).

however with the work being done here it has actually gotten quite high in the priority list. however im a bit stumped on where to start with this one. will there be tools like XCP-NG that will support this, or will I be relegated to installing something like rocky + XEN and qemu on top of that?

(PS. I suspect our use of android in a VM will overlap quite heavily with the automotive usecase anyways )

We'd like to get this stuff at some point in XCP-ng. The tech direction on GPUs is interesting (eg MiG on Nvidia side) where you put the "slicing" (vGPU) in the card itself via an API (instead of doing it in software) but the mediated device lead is also interesting. Hard to tell what will be the best solution (or if one will become the most used). At least, I can tell we actively monitor that

[olivier]

This level of robustness/security is very important to avoiding another 2015 Jeep Cherokee situation. (The only theoretically perfect solution is having drive systems and infotainment be entirely separate physical systems with 0 connection whatsoever, but given the current industry and consumer feature expectations, that's unlikely to happen.)

Yes, I think that's the whole point of having the static partitioning: you keep the simplicity & flexibility of having one hardware system that you can slice, while having a very reduced attack surface

[Quackdoc]

We'd like to get this stuff at some point in XCP-ng. The tech direction on GPUs is interesting (eg MiG on Nvidia side) where you put the "slicing" (vGPU) in the card itself via an API (instead of doing it in software) but the mediated device lead is also interesting. Hard to tell what will be the best solution (or if one will become the most used). At least, I can tell we actively monitor that

that's good to hear, I will for sure keep it on my radar then. heres to hoping good luck with integrating it

[stalkerg]

Maybe AMD will finally accept RADV as the default Vulkan driver?
It also seems like Rusticl will support admkfd it means ROCm will not really need at least for any OpenCL tasks.