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 > > complexity in there, and I really think we need to make that complexity > > explicit. Otherwise we'll always break vgt support for host systems by > > accident when working on upstream. So in my experience being explicit with > > these depencies massively reduces maintaince headaches longterm. > > I think that makes sense. vGT can leave alot of the lowlevel work such > as power management to i915 then, so we don't duplicate that code in vGT > and i915. It's not just the duplication, but interactions. And like I've said those are already making things in the i915 really messy. And then there's also all the new features like gpu scheduling, runtime pm and all that which we're constantly adding. Keeping up the appearance that i915 is in control on the host side but actually isn't would fall appart rather quickly I fear. > Stacking vGT on top of i915 also makes it alot easier to have it a > runtime option (just an additional kernel module you load when you need > it). Other way around vGT would be a hard dependency for i915, even if > you don't use it (you could compile it out probably, but distro kernels > can't do that if they want support vGT). We probably need to make a few changes to i915, maybe on the command submission side. But those should definitely be small enough that we don't need a compile time option for them. Furthermore the command submission code is getting rearchitected now (due to other features), so perfect time to make sure vgt will work, too. > Another note: Right now the guest display can only be sent to one of the > crtcs. Long term I want more options there, such as exporting the guest > display as dma-buf on the host so it can be blitted to some window. Or > even let the gpu encode the guest display as video, so we can send it > off over the network. I suspect that is also easier to implement if > i915 manages all resources and vGT just allocates from i915 what it > needs for the guest. Yeah that should be really simple to add, we already have abstraction for the different kinds of buffer objects (native shmem backed gem object, carveout/stolen mem, dma-buf imported, userptr). 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
