How gpu requests are trapped by kvmgt ?

[Adel Belkhiri]

OK, thanks for the clarification.

Le mar. 31 oct. 2017 à 02:13, Tian, Kevin <kevin.tian at intel.com> a écrit :

> i915_gem_request_add is just a software behavior. There could be many
> reasons resulting in different numbers observed between host/guest side. At
> least from virtualization p.o.v, emulation of execlist can also lead to
> such difference, say there are N requests captured from guest driver while
> that VM is not being scheduled in KVMGT at that time, later when that VM is
> scheduled N requests will be combined as one then sent to host i915.
>
>
>
> the only certain thing is that, every write to execlist port from guest
> will be trapped to KVMGT. checking numbers at points before write execlist
> in guest or after trap entry in host are not guaranteed to be same.
>
>
>
> Thanks
>
> Kevin
>
>
>
> *From:* intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org]
> *On Behalf Of *Adel Belkhiri
> *Sent:* Saturday, October 28, 2017 12:51 AM
>
>
> *To:* Tian, Kevin <kevin.tian at intel.com>
> *Cc:* intel-gvt-dev at lists.freedesktop.org
> *Subject:* Re: How gpu requests are trapped by kvmgt ?
>
>
>
> The number of "i915_gem_request_add" events (which indicate that a request
> is added to the i915 queue) in the VM is bigger than the number of the same
> event in the Host. The difference between the two numbers depends on the
> frequency of sending requests to the gpu inside the VM.
>
> To understand this behavior, I checked the function "execlists_dequeue"
> (in the file intel_lrc.c) in the VM and found that whenever there are many
> requests in the queue, to be submitted to the gpu, KVMGT is notified just
> once through "execlists_context_status_change".
>
>
>
>
>
> Le ven. 27 oct. 2017 à 01:05, Tian, Kevin <kevin.tian at intel.com> a écrit :
>
> Do you have more detail info where you actually add trace, and the exact
> number difference?
>
>
>
> *From:* Adel Belkhiri [mailto:adel.belkhiri at gmail.com]
> *Sent:* Friday, October 27, 2017 7:37 AM
> *To:* Tian, Kevin <kevin.tian at intel.com>
> *Cc:* intel-gvt-dev at lists.freedesktop.org
> *Subject:* Re: How gpu requests are trapped by kvmgt ?
>
>
>
> Thank you for your replay,
>
> What I wanted to say is that I found that the number of requests sent by
> the VM to the vgpu is different from the number of requests received by
> KVMGT. I used Ftrace to do the count.  I think the i915 driver of the VM
> sometimes combine multiple requests in just one request sent to KVMGT.
>
> Am I wrong ?
>
>
>
>
>
> Le mer. 25 oct. 2017 à 22:47, Tian, Kevin <kevin.tian at intel.com> a écrit :
>
> it’s decided by KVMGT. the real recipe is EPT, which is a CPU hw
> virtualization feature to decide which access in VM is trapped or not.
>
>
>
> *From:* intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org]
> *On Behalf Of *Adel Belkhiri
> *Sent:* Wednesday, October 25, 2017 11:06 PM
> *To:* intel-gvt-dev at lists.freedesktop.org
> *Subject:* How gpu requests are trapped by kvmgt ?
>
>
>
> Hi everybody,
>
> I have a question about the implementation of KVMGT. According to the
> documentation, the virtual machine, may send some requests to the gpu
> directly (Pass-through) and forward some other requests to the KVMGT
> module.
>
> I read the code of KVMGT but i didn't understand how requests are being
> sent directly to the gpu ? and who decide which request to be directly sent
> to the gpu or to be trapped by kvmgt ? Is it the graphics card driver of
> the VM (i915) or KVMGT ?
>
> Thanks a lot for your help.
>
> Yours.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20171031/c6e7c4da/attachment-0001.html>