[Intel-gfx] [PATCH v4 0/8] Add enlightenments for vGPU
Daniel Vetter
daniel at ffwll.ch
Wed Feb 11 00:06:59 PST 2015
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 at intel.com>
All merged, thanks for patches&review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list