From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: 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 09:59:56 +0000 [thread overview]
Message-ID: <5491541C.4070203@linux.intel.com> (raw)
In-Reply-To: <1418801629.18828.7.camel@nilsson.home.kraxel.org>
On 12/17/2014 07:33 AM, Gerd Hoffmann wrote:
> On Di, 2014-12-16 at 15:01 +0000, Tvrtko Ursulin wrote:
>> Hi,
>>
>> On 12/16/2014 02:41 PM, Gerd Hoffmann wrote:
>>>> I didn't figure out how each domain knowns which fences to use? They
>>>> know how many, but which ones?
>>>
>>> I think the guest doesn't have to know because mmio access is trapped by
>>> the hypervisor anyway.
>>
>> Okay.. so the point is to ensure no domain can hog all fences, but if
>> the hypervisor is already tracking everything why is this limiting
>> required then in the guest? Hypervisor could just say all fences are
>> allocated since it knows how much it gave out per guest.
>
> There is no dynamic allocation. Each guest gets a fixed number of
> fences assigned which it can use, pretty much like memory where each
> guest gets a fixed piece too.
>
> 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?
With this scheme it could be one guest wants more and can't get them
even if no one else is using any. If not limited they could be
dynamically allocated by the hypervisor, no?
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 9:59 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 [this message]
2014-12-17 11:06 ` Gerd Hoffmann
2014-12-17 11:25 ` Yu, Zhang
2014-12-17 11:50 ` Tvrtko Ursulin
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=5491541C.4070203@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=kraxel@redhat.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