Announcement

Collapse
No announcement yet.

Intel Pushes XenGT For GPU Access To Virtual Machines

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

  • Intel Pushes XenGT For GPU Access To Virtual Machines

    Phoronix: Intel Pushes XenGT For GPU Access To Virtual Machines

    Last month on Phoronix I wrote about Intel's new XenGT project as a means of mediated GPU pass-through to Xen-based guests. Today at the Linux Foundation Collaboration Summit is an update by an Intel engineer on the XenGT technology...

    http://www.phoronix.com/vr.php?view=MTY0NDU

  • #2
    I don't get it - what separates this from Xen's built-in GPU passthrough? Seems like the exact same thing IMO.

    Comment


    • #3
      Originally posted by schmidtbag View Post
      I don't get it - what separates this from Xen's built-in GPU passthrough? Seems like the exact same thing IMO.
      The article clearly states that it's different. Whereas passthrough gives the GPU to a particular VM, XenGT allows for sharing of the GPU between several VMs.

      Comment


      • #4
        Originally posted by kobblestown View Post
        The article clearly states that it's different. Whereas passthrough gives the GPU to a particular VM, XenGT allows for sharing of the GPU between several VMs.
        Oh whoops I didn't see that it said "same GPU". My bad.

        Comment


        • #5
          Will this just allow the integrated GPU to be shared or will it potentially allow other GPUs in the system to be shared between the guest and the host?

          edit: And presumably this will still only work for VT-d supporting CPUs?
          Last edited by Tom B; 03-27-2014, 08:21 PM.

          Comment


          • #6
            Originally posted by Tom B View Post
            edit: And presumably this will still only work for VT-d supporting CPUs?
            I don't think that's the case. From https://01.org/xen/blogs/srclarkx/20...lization-xengt

            Performance critical resources are passed through to a VM:

            Part of the global virtual memory space
            VM’s own per-process virtual memory spaces
            VM’s own allocated command buffers (actually in graphics memory)

            Other operations are privileged, and must be trapped and emulated by the mediator, including:

            MMIO/PIO
            PCI configuration registers
            GTT tables
            Submission of queued GPU commands
            With VT-d there would be no need to emulate these things. For the pass-through resources it looks like they are all memory-related and can be done with EPT because this is only for intel's IGPs where the video memory is shared with the system memory. I may be wrong though so please feel free to correct me.

            Comment


            • #7
              Very interesting news - but I suspect that the (early, at least) drawback would be that the drivers of the Host OS would have to be cooperative to a certain degree?

              Comment


              • #8
                Originally posted by Nognir View Post
                Very interesting news - but I suspect that the (early, at least) drawback would be that the drivers of the Host OS would have to be cooperative to a certain degree?
                This doesn't seem to be the case. From the link above:

                XenGT implements the mediator in dom0. This avoids adding complex device knowledge to Xen, and also permits a more flexible release model. In the meantime, we want to have a unified architecture to mediate all the VMs, including dom0, itself. So, the mediator is implemented as a separate module from dom0’s graphics driver. It brings a new challenge, that Xen must selectively trap the accesses from dom0’s driver while granting permission to the mediator. We call it a “deprivileged” dom0 mode.
                I interpret this to mean that there are no changes to host or guest drivers. Sounds too good to be true. But I guess it has performance impact so it's a sort of compromise between flexibility and performance (as usual).

                Anyway, it looks like a pretty good solution in case you only need the GPU for desktop effects and such. And that's all I need.

                Comment


                • #9
                  Originally posted by kobblestown View Post
                  Anyway, it looks like a pretty good solution in case you only need the GPU for desktop effects and such. And that's all I need.
                  Actually, at least according to the 01 link, with some optimization they may actually pass the 50% mark of native speed that will make it viable for both gaming and 3D/CAD applications.
                  Remember that unlike VT-d based solutions, mutiple-VMs + host can share the same GPU (as the mediator runs in dom0) making it far more viable solution for desktop virtualization.

                  - Gilboa
                  DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                  SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                  BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                  LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                  Comment

                  Working...
                  X