[Intel-gfx] [PATCH v3 0/8] Add enlightenments for vGPU

[Yu, Zhang]

On 11/14/2014 6:17 PM, Daniel Vetter wrote:
> On Thu, Nov 13, 2014 at 08:02:41PM +0800, Yu Zhang 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 Virtual
>> Machine (VM). VMs can directly access performance-critical
>> resources, without intervention from the hypervisor in most
>> cases, while privileged operations from VMs are trap-and-emulated
>> at minimal cost. For detail, please refer to
>> https://01.org/xen/blogs/wangbo85/2014/intel-gvt-gxengt-pubic-release
>>
>> 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 another patchset.
>>
>> 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 w/o hypervisor's intervention,
>> e.g. filling textures or queuing commands. However w/ 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 w/o 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 (w/ 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.
>
> I think this looks good now overall, so please find someone from the i915
> kernel team to review the details. You might need to poke managers to make
> that happen ;-)
> -Daniel
Thanks a lot, Daniel.
This is great. :-)

Yu
>