[Intel-gfx] [PATCH v4 0/8] Add enlightenments for vGPU
Yu, Zhang
yu.c.zhang at linux.intel.com
Tue Feb 10 23:47:02 PST 2015
On 2/10/2015 8:11 PM, 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>
Thank you very much, Tvrtko. This is great. :-)
Btw, should I resend another version patch series, which add the
"Reviewed-by" line, or will Daniel directly merge these patches and add
the "Reviewed-by" at that time? I'm willing to take whatever actions
necessary, but I'm not familiar with this process. Thanks again. :)
Yu
>
> Regards,
>
> Tvrtko
>
>
More information about the Intel-gfx
mailing list