From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, Jike Song <jike.song@intel.com>
Cc: Daniel <daniel.vetter@intel.com>,
"intel-gfx@lists.freedesktop.org"
<"intel-gfx@lists.freedesktop.org>, "@intel.com>,
Vetter@freedesktop.org
Subject: Re: [PATCH 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g.
Date: Fri, 10 Oct 2014 16:23:52 +0800 [thread overview]
Message-ID: <54379798.1060301@linux.intel.com> (raw)
In-Reply-To: <54295335.8090203@intel.com>
On 9/29/2014 8:40 PM, Jike Song wrote:
> On 09/29/2014 08:16 PM, Chris Wilson wrote:
>> On Mon, Sep 29, 2014 at 07:44:56PM +0800, Jike Song wrote:
>>> On 09/19/2014 03:25 PM, Chris Wilson wrote:
>>>> Now, given that these are simply trapped memory access, wouldn't it be
>>>> simply to have:
>>>>
>>>> struct i915_virtual_gpu {
>>>> struct vgt_if *if;
>>>> } vgu;
>>>>
>>>> static inline bool intel_vgpu_active(struct drm_i915_private *i915)
>>>> { return i915->vgpu.if; }
>>>>
>>>> then you have constructs like
>>>> void i915_check_vgpu(struct drm_i915_private *i915)
>>>> {
>>>> struct vgt_if *if;
>>>>
>>>> if = i915->regs + VGT_PVINFO_PAGE;
>>>> if (if->magic != VGT_MAGIC)
>>>> return;
>>>>
>>>> if (INTEL_VGT_IF_VERSION !=
>>>> INTEL_VGT_IF_VERSION_ENCODE(if->version_major,
>>>> if->version_minor))
>>>> return;
>>>>
>>>>
>>>> i915->vgpu.if = if;
>>>> }
>>>>
>>>> And later, for example:
>>>>
>>>> if (intel_vgpu_active(dev_priv))
>>>> dev_priv->num_fence_regs = dev_priv->vgpu.if->fence_num;
>>>>
>>>
>>> Hi Chris, sorry that I didn't understand you correctly. After discussion
>>> with Yu today, I realized that unfortunately, the vgt_if can't be
>>> dereferenced directly.
>>>
>>> There are several reasons:
>>>
>>> - dereferencing a MMIO address will be complained by sparse(1)
>>>
>>> - for Guest VM, such accesses will be trapped by hypervisor, and
>>> hence emulated correctly; However this doesn't work for Host(e.g.
>>> Domain 0 of Xen, the Linux host KVM resides in). For host, we used
>>> a proactive mechanism to redirect i915 MMIO accesses to vgt,
>>> the GPU device-model, for the sake of central management & sharing
>>> among VMs, including host.
>>
>> You only need to be careful during vgpu detection. After that you know
>> everything is safe. If you do the detection during intel_uncore_init(),
>> or similar, you can use raw mmio access and explict sparse annotations
>> to do the right thing.
>> -Chris
>
> Hi Chris,
>
> Thanks for your suggestion, however, it addressed issue #1 but not issue
> #2.
> I'd like to give a detailed explanation :)
>
> For Guest i915 driver, when accessing a MMIO reg, it goes:
>
> whatever I915_READ/readl or direct dereferencing(addr)
> addr is translated to gpa(guest physical address) by guest
> paging structure
> hypervisor trapped the gpa access and forward it to vgt
> vgt_emulate_read32(vgt instance of guest, gpa)
>
>
> The real problem is, when running as the host gpu driver, i915 MMIO/GTT
> accesses are:
>
> 1) every difficult to trap, say the domain 0 of Xen hypervisor; or
> 2) impossible to trap, say KVM(In KVM, the host i915 is running in
> the very same
> privilege level and root mode as KVM hypervisor.)
>
> So, for Host i915 driver, when accessing a MMIO reg, it goes:
>
> I915_READ(addr)
> gen6_read32(addr)
> offset = addr - dev_priv->regs
> vgt_mmio_readl(the vgt instance of host, offset)
> .. some processing ..
> if (passed-throuth)
> readl(offset + dev_priv->regs)
> else
> pa = BAR0 + offset
> vgt_emulate_read32(vgt instance of host, pa)
>
>
> The vgt_if corresponds to the PVINFO page, not passed-through(actually
> it doesn't physically exist),
> should fall into the "else" above.
>
> Given that ... Yes we can dereference pointers for guest here, but
> consider that we'll
> deal with host in the future ...
>
Hi Chris,
Any comments on this issue?
The host side patches were sent out by Jike last week. As you can see
in his patch, the I915_READ/WRITEs are redefined, and the MMIO accesses
are mediated to vgt, by offset of the regs, instead of by read/write
(dev_priv->regs + offset) for host i915.
So, in order to let i915 in the host side access the PVINFO page
successfully, could we still use the I915_READ/WRTE, and keep the
vgpu_active flag when detecting virtual gpu? :)
Thanks
Yu
>
> --
> Thanks,
> Jike
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
next prev parent reply other threads:[~2014-10-10 8:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 18:47 [PATCH 0/8] Add enlightenments for vGPU Jike Song
2014-09-19 18:47 ` [PATCH 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g Jike Song
2014-09-19 7:25 ` Chris Wilson
2014-09-19 10:23 ` Jike Song
2014-09-29 11:44 ` Jike Song
2014-09-29 12:08 ` Yu, Zhang
2014-09-29 12:16 ` Chris Wilson
2014-09-29 12:40 ` Jike Song
2014-10-10 8:23 ` Yu, Zhang [this message]
2014-09-19 16:02 ` Daniel Vetter
2014-09-19 16:07 ` Daniel Vetter
2014-09-19 21:39 ` Tian, Kevin
2014-09-19 18:47 ` [PATCH 2/8] drm/i915: Adds graphic address space ballooning logic Jike Song
2014-09-19 8:05 ` Chris Wilson
2014-09-19 16:04 ` Daniel Vetter
2014-09-19 18:21 ` Tian, Kevin
2014-09-19 20:00 ` Chris Wilson
2014-09-23 8:26 ` Daniel Vetter
2014-09-23 9:19 ` Chris Wilson
2014-09-23 11:25 ` Daniel Vetter
2014-09-24 12:35 ` Zhang, Yu
2014-09-24 13:21 ` Chris Wilson
2014-09-26 8:26 ` Zhang, Yu
2014-09-26 8:48 ` Chris Wilson
2014-09-26 8:46 ` Yu, Zhang
2014-09-24 13:23 ` Daniel Vetter
2014-09-19 18:47 ` [PATCH 3/8] drm/i915: Partition the fence registers for vgpu in i915 driver Jike Song
2014-09-19 18:47 ` [PATCH 4/8] drm/i915: Disable framebuffer compression for i915 driver in VM Jike Song
2014-09-19 8:07 ` Chris Wilson
2014-09-22 7:10 ` Jike Song
2014-09-22 11:28 ` Chris Wilson
2014-09-19 18:47 ` [PATCH 5/8] drm/i915: Add the display switch logic for vgpu in i915 driver Jike Song
2014-09-19 8:14 ` Chris Wilson
2014-09-19 11:37 ` Wang, Zhi A
2014-09-19 16:09 ` Daniel Vetter
2014-09-29 6:31 ` Zhiyuan Lv
2014-09-29 12:30 ` Daniel Vetter
2014-09-30 10:25 ` Zhiyuan Lv
2014-09-30 10:56 ` Daniel Vetter
2014-09-19 18:47 ` [PATCH 6/8] drm/i915: Disable power management for i915 driver in VM Jike Song
2014-09-19 8:16 ` Chris Wilson
2014-09-19 18:47 ` [PATCH 7/8] drm/i915: Create vgpu specific write MMIO to reduce traps Jike Song
2014-09-19 6:59 ` Chris Wilson
2014-09-19 7:43 ` Jike Song
2014-09-19 18:47 ` [PATCH 8/8] drm/i915: Support alias ppgtt in VM if ppgtt is enabled Jike Song
2014-09-19 8:25 ` Chris Wilson
2014-09-22 11:17 ` Jike Song
2014-09-22 11:27 ` Chris Wilson
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=54379798.1060301@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc="intel-gfx@lists.freedesktop.org>, "@intel.com \
--cc=Vetter@freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=jike.song@intel.com \
/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