From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yu, Zhang" Subject: Re: [PATCH v2 0/8] Add enlightenments for vGPU Date: Wed, 22 Oct 2014 15:03:56 +0800 Message-ID: <544756DC.6000603@linux.intel.com> References: <1413524239-8614-1-git-send-email-yu.c.zhang@linux.intel.com> <20141021161626.GB26941@phenom.ffwll.local> <20141021165117.GD26941@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTP id C49026E266 for ; Wed, 22 Oct 2014 00:11:03 -0700 (PDT) In-Reply-To: <20141021165117.GD26941@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On 10/22/2014 12:51 AM, Daniel Vetter wrote: > On Tue, Oct 21, 2014 at 06:16:26PM +0200, Daniel Vetter wrote: >> On Fri, Oct 17, 2014 at 01:37:11PM +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, were 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 and 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. >>> >>> 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 write MMIO to reduce traps >>> drm/i915: Support alias ppgtt in VM if ppgtt is enabled >>> >>> drivers/gpu/drm/i915/i915_dma.c | 11 +++ >>> drivers/gpu/drm/i915/i915_drv.h | 12 +++ >>> drivers/gpu/drm/i915/i915_gem.c | 5 + >>> drivers/gpu/drm/i915/i915_gem_gtt.c | 186 +++++++++++++++++++++++++++++++++++- >>> drivers/gpu/drm/i915/i915_vgt_if.h | 93 ++++++++++++++++++ >>> drivers/gpu/drm/i915/intel_pm.c | 8 ++ >>> drivers/gpu/drm/i915/intel_uncore.c | 22 +++++ >>> 7 files changed, 334 insertions(+), 3 deletions(-) >>> create mode 100644 drivers/gpu/drm/i915/i915_vgt_if.h >> >> I seem to have two v2 versions of this patch series. Anything changed or >> why the resend? I didn't see any comment on the older version ... > > Well, looked through it anyway. On a high level this looks good for the > vgt integration for guests. I think we need some polish though still, > specifically for documentation. > > - Please extract all the various intel_vgt_* functions spread all over the > tree into a new i915_vgt_if.c (or intel_vgt.c, but then the header > should be changed, too I think). > > - Please add kerneldoc to all the functions which are non-static and so > used by the driver outside of your kernel module. > > - Please add a DOC: section detailing some of the high-level design > considerations of vGT and also put that into the new file. I think in > the future we should also keep the guest<->host abi revisions in there > (i.e. the stuff in PV_INFO). Sure. Thanks! > > - Please pull all the new documentation together and integrate it into the > i915 section of the drm docbook. A good place is probably a new > subsection "Paravirtualized Guest Support (vGPU)" under the driver core > section. How about subsection name "Intel GVT-g Guest Support(vGPU)"? :) > > There's quite a few i915 driver subsystems which are already nicely > documented like this, but I also have a small howto: > > http://blog.ffwll.ch/2014/06/documentation-for-drmi915.html Thanks! This blog helps a lot. :) > > Cheers, Daniel >