From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Shan, Haitao" <haitao.shan@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"White, Michael L" <michael.l.white@intel.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
"Li, Susie" <susie.li@intel.com>,
"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Haron, Sandra" <sandra.haron@intel.com>
Subject: Re: [RFC] XenGT - An Mediated Graphics Passthrough Solution from Intel
Date: Mon, 9 Sep 2013 15:27:35 -0400 [thread overview]
Message-ID: <20130909192735.GB4232@phenom.dumpdata.com> (raw)
In-Reply-To: <CE53E3FE.61CF%haitao.shan@intel.com>
On Mon, Sep 09, 2013 at 12:46:23PM +0000, Shan, Haitao wrote:
> Hi, Xen Experts,
>
> This email is aimed at a first time disclosure of project XenGT, which is
> a Graphics virtualization solution based on Xen.
>
>
>
> As you can see, requirements for GPU to be sharable among virtual machines
> have been constantly rising. The targeted usage model might be
> accelerating tasks ranging from gaming, video playback, fancy GUIs,
> high-performance computing (GPU-based). This trend is observed on both
> client and cloud. Efficient GPU virtualization is required to address the
> increasing demands.
>
>
> We have developed XenGT - a prototype based on a mediated passthrough
> architecture. We support running a native graphics driver in multiple VMs
> to achieve high performance. A specific mediator owns the scheduling and
> sharing hardware resources among all the virtual machines. By saying
> mediated pass-through, we actually divide graphics resource to two
> categories: performance critical and others. We partition performance
> critical resources for VM's direct access like pass-through, while save
> and restore others.
>
>
>
> XenGT implements the mediator in dom0, called vgt driver. 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. Thus, We developed a ³deprivileged²
> dom0 mode, which essentially trapped Dom0's access to selected resources
> (graphics resources in XenGT case) and forwarded to vgt driver (which is
> also in Dom0) for processing.
But could be in another domain itself - an device driver domain right?
>
>
> Performance critical resources are:
> - 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)
>
>
> Others are:
> - MMIO/PIO
> - PCI configuration registers
> - GTT tables
> - Submission of queued GPU commands
>
> Right now, we support 4 accelerated VMs: Dom0 + 3 HVM DomUs. We've
> conducted verifications based on Ubuntu 12.04 and 13.04. Tests conducted
> in VM include but are not limited to 3D gaming, media playbacks, 2D
> accelerations.
>
> We believe the architecture itself can be general so that different GPUs
> can all use this mediated passthrough concept. However, we only developed
> codes based on Intel 4th Core Processor with integrated Graphics. Note
> that we don't require VT-d to run our solution.
>
> If you have interests in trying, you can refer to the attached setup
> guide, which provides step-to-step details on building/configuring/running
> XenGT.
>
> Source code is made available at github:
> Xen: https://github.com/01org/XenGT-Preview-xen.git
> Linux: https://github.com/01org/XenGT-Preview-kernel.git
> Qemu: https://github.com/01org/XenGT-Preview-qemu.git
Yeey! Awesome! Thank you for sharing that.
>
> Any comments are welcome!
>
>
> Special note: We are making this code available to general public since we
> take community's involvement and feedbacks seriously. However, while we've
> tested our solution with various workloads, the code is only at pre-alpha
> stage. Hangs might happen, so please don't try it on the system that
> hosting critical data for you.
>
> Shan Haitao
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-09-09 19:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 12:46 [RFC] XenGT - An Mediated Graphics Passthrough Solution from Intel Shan, Haitao
2013-09-09 19:27 ` Konrad Rzeszutek Wilk [this message]
2013-09-09 19:53 ` Tian, Kevin
2013-09-09 20:59 ` Matt Wilson
2013-09-09 21:14 ` Cui, Dexuan
2013-09-09 21:38 ` Matt Wilson
2013-09-09 23:19 ` Shan, Haitao
2013-09-10 8:47 ` Fabio Fantoni
2013-09-10 14:02 ` Tian, Kevin
2013-09-10 8:38 ` Paul Durrant
2013-09-10 13:57 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130909192735.GB4232@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=david.j.cowperthwaite@intel.com \
--cc=eddie.dong@intel.com \
--cc=haitao.shan@intel.com \
--cc=kevin.tian@intel.com \
--cc=michael.l.white@intel.com \
--cc=sandra.haron@intel.com \
--cc=susie.li@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.