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
>
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox