On Tue, Feb 10, 2015 at 12:11:02PM +0000, Tvrtko Ursulin wrote: > On 02/10/2015 11:05 AM, Yu Zhang wrote: > >This patch set includes necessary code changes when i915 driver > >runs inside a VM. Though ideally we can run an unmodified i915 > >driver in VM, adding such enlightenments can greatly reduce the > >virtualization complexity in orders of magnitude. Code changes > >for the host side, which includes the actual Intel GVT-g > >implementation, will be sent out in other patches. > > > >The primary change introduced here is to implement so-called > >"address space ballooning" technique. XenGT partitions global > >graphics memory among multiple VMs, so each VM can directly > >access a portion of the memory without hypervisor's intervention, > >e.g. filling textures or queuing commands. However with the > >partitioning an unmodified i915 driver would assume a smaller > >graphics memory starting from address ZERO, so requires XenGT > >core module (vgt) to translate the graphics address between > >'guest view' and 'host view', for all registers and command > >opcodes which contain a graphics memory address. To reduce the > >complexity, XenGT introduces "address space ballooning", by > >telling the exact partitioning knowledge to each guest i915 > >driver, which then reserves and prevents non-allocated portions > >from allocation. Then vgt module only needs to scan and validate > >graphics addresses without complexity of translation. > > > >Note: The partitioning of global graphics memory may break some > >applications, with large objects in the aperture, because current > >userspace assumes half of the aperture usable. That would need > >separate fix either in user space (e.g. remove assumption in mesa) > >or in kernel (with some faulting mechanism). > > > >The partitioning knowledge is conveyed through a reserved MMIO > >range, called PVINFO, which will be architecturally reserved in > >future hardware generations. Another information carried through > >PVINFO is about the number of fence registers. As a global resource, > >XenGT also partitions them among VMs. > > > >Other changes are trivial as optimizations, to either reduce the > >trap overhead or disable power management features which don't > >make sense in a virtualized environment. > > > > > >Yu Zhang (8): > > drm/i915: Introduce a PV INFO page structure for Intel GVT-g. > > drm/i915: Adds graphic address space ballooning logic > > drm/i915: Partition the fence registers for vGPU in i915 driver > > drm/i915: Disable framebuffer compression for i915 driver in VM > > drm/i915: Add the display switch logic for vGPU in i915 driver > > drm/i915: Disable power management for i915 driver in VM > > drm/i915: Create vGPU specific MMIO operations to reduce traps > > drm/i915: Support alias ppgtt in VM if ppgtt is enabled > > All my comments have been addressed (and I especially like the ASCII diagram > of the memory space!) so you can put my r-b on all the patches from this > series: > > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> All merged, thanks for patches&review. -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
