How gpu requests are trapped by kvmgt ?
Tian, Kevin
kevin.tian at intel.com
Tue Oct 31 06:13:34 UTC 2017
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<mailto: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<mailto:adel.belkhiri at gmail.com>]
Sent: Friday, October 27, 2017 7:37 AM
To: Tian, Kevin <kevin.tian at intel.com<mailto:kevin.tian at intel.com>>
Cc: intel-gvt-dev at lists.freedesktop.org<mailto: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<mailto: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<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<mailto: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/136a447d/attachment-0001.html>
More information about the intel-gvt-dev
mailing list