All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 0/8] Add enlightenments for vGPU
Date: Wed, 22 Oct 2014 14:56:10 +0800	[thread overview]
Message-ID: <5447550A.5020005@linux.intel.com> (raw)
In-Reply-To: <20141021161626.GB26941@phenom.ffwll.local>

Hi Daniel,

   Thanks a lot for your reply. Indeed, I sent two v2 patches, because
the format of the first v2 patchset is incorrect - I forgot to add the
what changed part in those messages. :)

Yu

On 10/22/2014 12:16 AM, 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 ...
> -Daniel
>

  parent reply	other threads:[~2014-10-22  7:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17  5:37 [PATCH v2 0/8] Add enlightenments for vGPU Yu Zhang
2014-10-17  5:37 ` [PATCH v2 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g Yu Zhang
2014-10-17  5:37 ` [PATCH v2 2/8] drm/i915: Adds graphic address space ballooning logic Yu Zhang
2014-10-17  5:37 ` [PATCH v2 3/8] drm/i915: Partition the fence registers for vgpu in i915 driver Yu Zhang
2014-10-17  5:37 ` [PATCH v2 4/8] drm/i915: Disable framebuffer compression for i915 driver in VM Yu Zhang
2014-10-17  5:37 ` [PATCH v2 5/8] drm/i915: Add the display switch logic for vgpu in i915 driver Yu Zhang
2014-10-17  5:37 ` [PATCH v2 6/8] drm/i915: Disable power management for i915 driver in VM Yu Zhang
2014-10-17  5:37 ` [PATCH v2 7/8] drm/i915: Create vgpu specific write MMIO to reduce traps Yu Zhang
2014-10-17  5:37 ` [PATCH v2 8/8] drm/i915: Support alias ppgtt in VM if ppgtt is enabled Yu Zhang
2014-10-21 16:16 ` [PATCH v2 0/8] Add enlightenments for vGPU Daniel Vetter
2014-10-21 16:51   ` Daniel Vetter
2014-10-22  7:03     ` Yu, Zhang
2014-10-22 10:27       ` Daniel Vetter
2014-10-22  6:56   ` Yu, Zhang [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-16  6:24 Yu Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5447550A.5020005@linux.intel.com \
    --to=yu.c.zhang@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.