public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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
>
>

  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