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 hardware. I haven't really seen the other side but it looks like with vgt we actually have two drivers fighting over the hardware, which requires the various hooks to avoid disaster. The drm subsystem is littered with such attempts, and they all didn't end up in a pretty way. So way can't we have the vgt support for guests sit on top of i915, using the i915 functions to set up pagetables, contexts and reserve gtt areas for the guests? Then we'd have just one driver in control of the hardware, and vgt on the host side would just look like a really crazy interace layer between virtual hosts and the low-level driver, similar to who the execbuf ioctl is a really crazy interface between userspace and the low-level driver.
Yes we can do this, but that also means lots of pollution to existing i915 codes, only for virtualization purpose. Currently vgt has pretty abstractions for both host i915 and guest graphics drivers, mixing vgt and host i915 means breaking that. I believe a vgt-integrated repository will be better to look at :)
Cheers, Daniel
-- Thanks, Jike _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
