From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 3/8] drm/i915: Partition the fence registers for vGPU in i915 driver
Date: Wed, 17 Dec 2014 11:50:13 +0000 [thread overview]
Message-ID: <54916DF5.3000004@linux.intel.com> (raw)
In-Reply-To: <5491682B.9050706@linux.intel.com>
On 12/17/2014 11:25 AM, Yu, Zhang wrote:
> On 12/17/2014 7:06 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>>> It's not possible to allow guests direct access to the fence registers
>>>> though. And if every fence register access traps into the hypervisor
>>>> anyway the hypervisor can easily map the guest virtual fence to host
>>>> physical fence, so there is no need to tell the guest which fences it
>>>> owns, the number of fences is enough.
>>>
>>> That exactly is the part I don't understand - if it is not required to
>>> tell the guest which fences it owns, why it is required to say how many?
>>
>> There is a fixed assignment of fences to guests, so it's a fixed number.
>> But as the hypervisor is involved in any fence access anyway there is no
>> need for the guest to know which of the fences it owns, the hypervisor
>> can remap that transparently for the guest, without performance penalty.
> Thanks Gerd. Exactly.
> Although fence registers are parititioned to vGPU, it is not necessary
> for a vGPU to know the physical mmio addresses of the allocated fence
> registers.
> For example, vGPU 1 with fence size 4 can access the fence registers
> from 0x100000-10001f; at the same time, vGPU 2 with fence size 8 can
> access the fence registers from 0x100000-0x10003f. Although this seems
> conflicting, it does not matter. Because these mmio addresses are all
> supposed to be trapped in the host side, which will keep a record of the
> real fence offset of different vGPUs(say 0 for vGPU 1 and 4 for vGPU 2),
> and then does the remapping. Therefore, the physical operations on the
> fence register will be performed by host code on different ones(say,
> 0x100000-10001fh for vGPU 1 and 0x100020-0x10005f for vGPU 2).
Okay, I think I get it now. What I had in mind is not really possible
without a dedicated hypervisor<->guest communication channel. Or in
other words you would have to extend the way i915 allocates them from
mmio writes to something bi-directional.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-12-17 11:50 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 12:02 [PATCH v3 0/8] Add enlightenments for vGPU Yu Zhang
2014-11-13 12:02 ` [PATCH v3 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g Yu Zhang
2014-12-11 17:33 ` Tvrtko Ursulin
2014-12-15 8:12 ` Daniel Vetter
2014-12-16 12:51 ` Yu, Zhang
2014-12-16 13:19 ` Tvrtko Ursulin
2014-12-17 2:49 ` Yu, Zhang
2014-12-17 5:04 ` Tian, Kevin
2014-11-13 12:02 ` [PATCH v3 2/8] drm/i915: Adds graphic address space ballooning logic Yu Zhang
2014-11-14 10:16 ` Daniel Vetter
2014-11-14 12:00 ` Yu, Zhang
2014-12-12 13:00 ` Tvrtko Ursulin
2014-12-16 13:22 ` Yu, Zhang
2014-12-16 13:41 ` Tvrtko Ursulin
2014-12-16 14:39 ` Gerd Hoffmann
2014-12-16 15:15 ` Tvrtko Ursulin
2014-12-17 3:10 ` Yu, Zhang
2014-12-17 5:20 ` Tian, Kevin
2014-12-17 10:06 ` Tvrtko Ursulin
2014-12-17 5:57 ` Tian, Kevin
2014-11-13 12:02 ` [PATCH v3 3/8] drm/i915: Partition the fence registers for vGPU in i915 driver Yu Zhang
2014-12-12 13:07 ` Tvrtko Ursulin
2014-12-16 13:32 ` Yu, Zhang
2014-12-16 13:44 ` Tvrtko Ursulin
2014-12-16 14:41 ` Gerd Hoffmann
2014-12-16 15:01 ` Tvrtko Ursulin
2014-12-17 7:33 ` Gerd Hoffmann
2014-12-17 9:59 ` Tvrtko Ursulin
2014-12-17 11:06 ` Gerd Hoffmann
2014-12-17 11:25 ` Yu, Zhang
2014-12-17 11:50 ` Tvrtko Ursulin [this message]
2014-12-17 17:10 ` Daniel Vetter
2014-12-17 17:11 ` Daniel Vetter
2014-12-18 0:36 ` Tian, Kevin
2014-12-18 8:08 ` Daniel Vetter
2014-12-18 8:39 ` Tian, Kevin
2014-12-17 4:58 ` Tian, Kevin
2014-11-13 12:02 ` [PATCH v3 4/8] drm/i915: Disable framebuffer compression for i915 driver in VM Yu Zhang
2014-12-12 13:13 ` Tvrtko Ursulin
2014-12-17 3:15 ` Yu, Zhang
2014-11-13 12:02 ` [PATCH v3 5/8] drm/i915: Add the display switch logic for vGPU in i915 driver Yu Zhang
2014-12-12 13:18 ` Tvrtko Ursulin
2014-12-15 8:16 ` Daniel Vetter
2014-12-17 3:17 ` Yu, Zhang
2014-11-13 12:02 ` [PATCH v3 6/8] drm/i915: Disable power management for i915 driver in VM Yu Zhang
2014-12-12 13:27 ` Tvrtko Ursulin
2014-12-17 3:25 ` Yu, Zhang
2014-11-13 12:02 ` [PATCH v3 7/8] drm/i915: Create vGPU specific write MMIO to reduce traps Yu Zhang
2014-12-12 13:31 ` Tvrtko Ursulin
2014-12-17 7:28 ` Yu, Zhang
2014-11-13 12:02 ` [PATCH v3 8/8] drm/i915: Support alias ppgtt in VM if ppgtt is enabled Yu Zhang
2014-11-14 0:29 ` [PATCH v3 8/8] drm/i915: Support alias ppgtt in VM if shuang.he
2014-12-12 13:37 ` [PATCH v3 8/8] drm/i915: Support alias ppgtt in VM if ppgtt is enabled Tvrtko Ursulin
2014-11-14 10:17 ` [PATCH v3 0/8] Add enlightenments for vGPU Daniel Vetter
2014-11-14 12:01 ` Yu, Zhang
2014-12-11 17:03 ` Tvrtko Ursulin
2014-12-15 8:18 ` Daniel Vetter
2014-12-15 9:16 ` Jani Nikula
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=54916DF5.3000004@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=yu.c.zhang@linux.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.