All of lore.kernel.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 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.