Re: [PATCH v3 0/8] Add enlightenments for vGPU

From: Daniel Vetter <daniel@ffwll.ch>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 0/8] Add enlightenments for vGPU
Date: Fri, 14 Nov 2014 11:17:12 +0100	[thread overview]
Message-ID: <20141114101712.GJ25711@phenom.ffwll.local> (raw)
In-Reply-To: <1415880169-7656-1-git-send-email-yu.c.zhang@linux.intel.com>

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx