Results 1 to 9 of 9

Thread: Intel Pushes XenGT For GPU Access To Virtual Machines

  1. #1
    Join Date
    Jan 2007
    Posts
    15,130

    Default 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. #2
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,386

    Default

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

  3. #3
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    76

    Default

    Quote 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.

  4. #4
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,386

    Default

    Quote 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.

  5. #5
    Join Date
    Feb 2014
    Posts
    28

    Default

    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 at 08:21 PM.

  6. #6
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    76

    Default

    Quote 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.

  7. #7
    Join Date
    Oct 2007
    Posts
    14

    Default

    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?

  8. #8
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    76

    Default

    Quote 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.

  9. #9
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    600

    Default

    Quote 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, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •