Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    As I've written about a few times in recent months, AMD has been enhancing GPU support for use under Xen virtualization. Their interests in Xen weren't clear to this point given that KVM virtualization tends to be the dominant solution these days when it comes to open-source Linux virtualization. Now it's been revealed that the AMD GPU interests in Xen stem from an in-vehicle infotainment play...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why not use KVM? Is this because they are trying to decouple the kernel and hypervisor?

    Comment


    • #3
      Originally posted by mantide View Post
      Why not use KVM? Is this because they are trying to decouple the kernel and hypervisor?
      I can't think of any singular reason, but there could be a couple small reasons, one such reason could be ofc what you said, another could be better security. xen's security model is quite strong so I could see that being a factor. however I dont really see any of these being one major reason, it's likely a bunch of smaller reasons, or it could simply be that xen has a better management tool for such a use.

      you can easily use KVM+Qemu in a car and get perfectly adequate results. don't get me wrong, I've actually done quite similar things before using qemu thanks to qemu emulating can. (wish so badly there was a virtio can device though) (I was actually doing it before opensynergy started publishing their work hehehe). so I think KVM is more then adequate solution. so I can't really think of any single major reason to choose xen over kvm

      Comment


      • #4
        Originally posted by mantide View Post
        Why not use KVM? Is this because they are trying to decouple the kernel and hypervisor?
        That automotive industry in general tends to use Xen rather than KVM.

        Comment


        • #5
          Michael

          Typo

          "VirtIO GPU ans passthrough GPU support interests for Xen."

          Probably you meant and?

          Comment


          • #6
            Originally posted by agd5f View Post

            That automotive industry in general tends to use Xen rather than KVM.
            Yes, but why?
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              Originally posted by darkbasic View Post

              Yes, but why?
              Corporate support contracts. Xen has a lot of industry support and was there first. It's also host OS agnostic. KVM is only Linux.

              Citrix is one of the 800lb gorillas in the enterprise software market. They purchased XenSource some years ago. But Xen also has support from the Linux Foundation, Intel, AMD (as the article states), and other industry heavyweights. Corporations like service contracts for damned good reasons.

              Edit to add: Xen is also the only (far as I know) bare metal open source hypervisor. It doesn't need a host OS to run it. So basically the hardware bootstraps firmware and from there directly into Xen's code, which then boots each OS on top of it, which can be any OS supported either paravirtualization or hardware virtualization modes. It's extremely flexible. KVM can't do that. That alone probably has a great deal to do with its popularity. I don't need a host OS, and it will run just about any OS as a guest. Corporate support packages for hire + high flexibility? What's not to love from a corporate developer's point of view.
              Last edited by stormcrow; 05 July 2023, 12:47 PM.

              Comment


              • #8
                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
                Last edited by olivier; 05 July 2023, 02:40 PM.

                Comment


                • #9
                  Originally posted by olivier View Post
                  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
                  Nice, I only had the 30k ft overview of Xen. Thanks for further clarification, especially that it's not dependent on dom0 for C2 any more, I wasn't aware of that.

                  Edit to add: People shouldn't immediately jump to the conclusion that even if Xen becomes fully formally verified that the platform is completely secure. A platform is only as secure as its weakest link. However, microkernels are extremely good at isolating accidental faults such that they don't become a safety issue. That's a different kettle of fish from security issues even though there's overlaps in the domains. You can have a "safe" platform, and you can have a "secure" platform. The idea behind safety is that incidental, accidental, and even intentional damages can be isolated within specifications.

                  But as Schneier has said:

                  "You can't prevent. You can't defend. You can only detect and respond." And I might point out, that quick detection and response is in itself a form of prevention to prevent an incident from becoming a disaster.
                  Last edited by stormcrow; 05 July 2023, 03:30 PM.

                  Comment


                  • #10
                    Originally posted by olivier View Post
                    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
                    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 )

                    Comment

                    Working...
                    X