> From: Daniel Vetter
> Sent: Thursday, October 23, 2014 8:10 PM
>
> On Thu, Oct 23, 2014 at 01:01:28PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > Stuf like driver load/unload, suspend/resume, runtime pm and gpu reset
> are
> > > already supre-fragile as-is. Every time we change something in
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, October 23, 2014 4:56 PM
>
> On Thu, Oct 23, 2014 at 11:13:51AM +0800, Jike Song wrote:
> > On 10/22/2014 05:48 PM, Daniel Vetter wrote:
> > >So on a very high level I don't understand this design. F
On Thu, Oct 23, 2014 at 01:01:28PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Stuf like driver load/unload, suspend/resume, runtime pm and gpu reset are
> > already supre-fragile as-is. Every time we change something in there, a
> > bunch of related things fall apart. With vgt we'll have even more
Hi,
> I guess from a really high level this boils down to having a xen-like
> design (where the hypervisor and dom0 driver are separate, but cooperate
> somewhat) or kvm (where the virtualization sits on top of a normal
> kernel). Afaics the kvm model seems to have a lot more momentum overall.
Hi,
> Stuf like driver load/unload, suspend/resume, runtime pm and gpu reset are
> already supre-fragile as-is. Every time we change something in there, a
> bunch of related things fall apart. With vgt we'll have even more
> complexity in there, and I really think we need to make that complexity
On Thu, Oct 23, 2014 at 11:13:51AM +0800, Jike Song wrote:
> On 10/22/2014 05:48 PM, Daniel Vetter wrote:
> >So on a very high level I don't understand this design. For the guest side
> >it's completely clear that we need a bunch of hooks over the driver to
> >make paravirtualization work.
> >
> >B
On 10/22/2014 05:48 PM, Daniel Vetter wrote:
So on a very high level I don't understand this design. For the guest side
it's completely clear that we need a bunch of hooks over the driver to
make paravirtualization work.
But on the host side I expect the driver to be in full control of the
hardw
On Tue, Sep 30, 2014 at 06:05:30PM +0800, Jike Song wrote:
> Intel GVT-g (previously known as XenGT), is a complete GPU
> virtualization solution with mediated pass-through for 4th
> generation Intel Core processors - Haswell platform. This
> technology presents a virtual full-fledged GPU to each V
Intel GVT-g (previously known as XenGT), is a complete GPU
virtualization solution with mediated pass-through for 4th
generation Intel Core processors - Haswell platform. This
technology presents a virtual full-fledged GPU to each Virtual
Machine (VM). VMs can directly access performance-critical
r
