- 06 Mar, 2018 27 commits
-
-
Changbin Du authored
The implementation of current kvmgt implicitly setup dma mapping at MPT API gfn_to_mfn. First this design against the API's original purpose. Second, there is no unmap hit in this design. The result is that the dma mapping keep growing larger and larger. For mutl-vm case, they will consume IOMMU IOVA low 4GB address space quickly and so tons of rbtree entries crated in the IOMMU IOVA allocator. Finally, single IOVA allocation can take as long as ~70ms. Such latency is intolerable. To address both above issues, this patch introduced two new MPT API: o dma_map_guest_page - setup dma map for guest page o dma_unmap_guest_page - cancel dma map for guest page The kvmgt implements these 2 API. And to reduce dma setup overhead for duplicated pages (eg. scratch pages), two caches are used: one is for mapping gfn to struct gvt_dma, another is for mapping dma addr to struct gvt_dma. With these 2 new API, the gtt now is able to cancel dma mapping when page table is invalidated. The dma mapping is not in a gradual increase now. v2: follow the old logic for VFIO_IOMMU_NOTIFY_DMA_UNMAP at this point. Cc: Hang Yuan <hang.yuan@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Changbin Du <changbin.du@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
Fix below check error by using proper failure message output. drivers/gpu/drm/i915//gvt/handlers.c:1392 hws_pga_write() error: 'vgpu' dereferencing possible ERR_PTR() drivers/gpu/drm/i915//gvt/handlers.c:1402 hws_pga_write() error: 'vgpu' dereferencing possible ERR_PTR() Reviewed-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Zhenyu Wang authored
Fix below warning: drivers/gpu/drm/i915//gvt/handlers.c:323 gdrst_mmio_write() warn: inconsistent indenting Reviewed-by:
-
Zhenyu Wang authored
Fix below error with minor code refactor. CHECK drivers/gpu/drm/i915//gvt/handlers.c drivers/gpu/drm/i915//gvt/handlers.c:203 sanitize_fence_mmio_access() error: 'vgpu' dereferencing possible ERR_PTR() Reviewed-by:
-
Zhenyu Wang authored
Fix check error at CHECK drivers/gpu/drm/i915//gvt/kvmgt.c drivers/gpu/drm/i915//gvt/kvmgt.c:455 intel_vgpu_create() error: we previously assumed 'vgpu' could be null (see line 454) For failed vgpu create, just show error return in failure message. Reviewed-by:
-
Zhenyu Wang authored
Fix below warning by using proper ktime helper to calculate timeslice. CHECK drivers/gpu/drm/i915//gvt/sched_policy.c drivers/gpu/drm/i915//gvt/sched_policy.c:108 gvt_balance_timeslice() debug: sval_binop_signed: invalid divide LLONG_MIN/-1 drivers/gpu/drm/i915//gvt/sched_policy.c:108 gvt_balance_timeslice() debug: sval_binop_signed: invalid divide LLONG_MIN/-1 Reviewed-by:
-
Zhenyu Wang authored
Remove GVT-g private max port definition but use i915 one. Fix error caused by: drivers/gpu/drm/i915//gvt/handlers.c:871 dp_aux_ch_ctl_mmio_write() error: buffer overflow 'display->ports' 5 <= 5 Reviewed-by:
-
Zhenyu Wang authored
Fix below warning with proper usage. CHECK drivers/gpu/drm/i915//gvt/dmabuf.c drivers/gpu/drm/i915//gvt/dmabuf.c:462 intel_vgpu_get_dmabuf() error: 'vgpu' dereferencing possible ERR_PTR() Reviewed-by:
-
Weinan Li authored
There is one issue relates to Coarse Power Gating(CPG) on KBL NUC in GVT-g, vgpu can't get the correct default context by updating the registers before inhibit context submission. It always get back the hardware default value unless the inhibit context submission happened before the 1st time forcewake put. With this wrong default context, vgpu will run with incorrect state and meet unknown issues. The solution is initialize these mmios by adding lri command in ring buffer of the inhibit context, then gpu hardware has no chance to go down RC6 when lri commands are right being executed, and then vgpu can get correct default context for further use. v3: - fix code fault, use 'for' to loop through mmio render list(Zhenyu) v4: - save the count of engine mmio need to be restored for inhibit context and refine some comments. (Kevin) v5: - code rebase Cc: Kevin Tian <kevin.tian@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Weinan Li <weinan.z.li@intel.com> Signed-off-by:
-
Weinan Li authored
No functional change, just for easy to use. v4: - refine comment (Kevin) Signed-off-by:
-
Weinan Li authored
No functional change. This defination will also be used in future patchesi. v4: - refine patch description (Kevin) Signed-off-by:
-
Changbin Du authored
Define the masks better. Signed-off-by:
-
Changbin Du authored
We don't know how many page tables will be shadowed. It varies considerably corresponding to guest load. Radix tree is a better choice for us. Since Page Frame Number is used as key so most of the bits are common. Here is some performance data (duration in us) of looking up a element: Before: (aka. ppgtt_find_shadow_page) 0.308 0.292 0.246 0.432 0.143 ... 0.311 0.225 0.382 0.199 0.325 After: (aka. intel_vgpu_find_spt_by_mfn) 0.106 0.106 0.107 0.106 0.105 0.107 ... 0.107 0.109 0.105 0.108 This time I didn't get the early data of hash table. The data is measured when desktop is shown. As last change, the overall benchmark almost is not changed, but we get better scalability. Signed-off-by:
-
Changbin Du authored
This patch provide generic page_track infrastructure for write-protected guest page. The old page_track logic gets rewrote and now stays in a new standalone page_track.c. This page track infrastructure can be both used by vGUC and GTT shadowing. The important change is that it uses radix tree instead of hash table. We don't have a predictable number of pages that will be tracked. Here is some performance data (duration in us) of looking up a element: Before: (aka. intel_vgpu_find_tracked_page) 0.091 0.089 0.090 ... 0.093 0.091 0.087 ... 0.292 0.285 0.292 0.291 After: (aka. intel_vgpu_find_page_track) 0.104 0.105 0.100 0.102 0.102 0.100 ... 0.101 0.101 0.105 0.105 The hash table has good performance at beginning, but turns bad with more pages being tracked even no 3D applications are running. As expected, radix tree has stable duration and very quick. The overall benchmark (tested with Heaven Benchmark) marginally improved since this is not the bottleneck. What we benefit more from this change is scalability. Signed-off-by:
-
Changbin Du authored
Don't extend page_track to mpt layer. Keep MPT simple and clean. Meanwhile remove gtt.n_tracked_guest_page which doesn't make much sense. v2: clean up gtt.n_tracked_guest_page. Signed-off-by:
-
Changbin Du authored
The kvmgt's implementation of mpt api {set,unset}_wp_page is not real write-protection - the data get written before invoke this two api. As discussed, change the mpt api to match the real behavior. Signed-off-by: -
Changbin Du authored
The target structure of some functions is struct intel_vgpu_ppgtt_spt and their names are xxx_shadow_page. It should be xxx_shadow_page_table. Let's use short name 'spt' instead to reduce the length. As well as the hash table name. Signed-off-by:
-
Changbin Du authored
This is a another big one and the GVT shadow page management code is heavily refined. The new code only use struct intel_vgpu_ppgtt_spt to represent a vgpu shadow page table - w/ or wo/ a guest page associated with. A pure shadow page (no guest page associated) will be used to shadow splited 2M huge gtt. In this case, the spt.guest_page.gfn should be a zero. To search a existed shadow page table, we have two new interfaces: - intel_vgpu_find_spt_by_gfn(), find a spt by guest gfn. It must not be a pure spt. - intel_vgpu_find_spt_by_mfn, Find the spt using shadow page mfn in shadowed PTE. The oos_page management is remained as what is was. v2: Split some changes into small standalone patches. Signed-off-by:
-
Changbin Du authored
Make the shadow PTE population code clear. Later we will add huge gtt support based on this. v2: - rebase to latest code. Signed-off-by:
Zhi Wang <zhi.wang@intel.com> Signed-off-by:
-
Changbin Du authored
GTT entry has similar format with the CPU PTE. We'd prefer named macro instead of hardcode. Signed-off-by:
-
Changbin Du authored
Factor out these two interfaces so we can kill some duplicated code in scheduler.c. v2: - rename to intel_vgpu_{get,put}_ppgtt_mm - refine handle_g2v_notification Signed-off-by: -
Changbin Du authored
Accurate names help to avoid confusing so improve readability. Signed-off-by:
-
Changbin Du authored
This add a new macro gvt_vdbg_mm() to print more verbose logs for gtt shadowing. The added verbose logs are very useful for debugging. gvt_vdbg_mm() only comes into effect if VERBOSE_DEBUG is defined by the developer. Signed-off-by:
-
Changbin Du authored
Less code and use existed helper ggtt_set_host_entry. Signed-off-by:
-
Changbin Du authored
Separate ggtt and ppgtt since they are different. A little more code but straightforward. And move these helpers to gtt.c since that is the only client. Signed-off-by:
-
Changbin Du authored
If we manage an object with a reference count, then its life cycle must flow the reference count operations. Meanwhile, change the operation functions to generic name *put* and *get*. Signed-off-by:
-
Changbin Du authored
This is a big one and the GVT shadow graphic memory management code is heavily refined. The new code is more straightforward with less code. The struct intel_vgpu_mm is restructured to be clearly defined, use accurate names and some of the original fields are removed which are really redundant. Now we only manage ppgtt mm object with mm->ppgtt_mm.lru_list. No need to mix ppgtt and ggtt together, since one vGPU only has one ggtt object. v4: Don't invoke ppgtt_free_all_shadow_page before intel_vgpu_destroy_all_ppgtt_mm. v3: Add GVT_RING_CTX_NR_PDPS to avoid confusing about the PDPs. v2: Split some changes into small standalone patches. Signed-off-by:
-
- 05 Mar, 2018 1 commit
-
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 02 Mar, 2018 12 commits
-
-
Michal Wajdeczko authored
If we fail to authenticate HuC firmware, we should change its load status to FAIL. While around, print HUC_STATUS on firmware verification failure. v2: keep the variables sorted by length (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Michal Wajdeczko authored
We want to use higher level 'uc' functions as the main entry points to the GuC/HuC code to hide some details and keep code layered. While here, move call to disable_guc_interrupts after sending suspend action to the GuC to allow it work also with CTB as comm mechanism. v2: update commit msg (Sagar) Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Chris Wilson authored
During reset/wedging, we have to clean up the requests on the timeline and flush the pending interrupt state. Currently, we are abusing the irq disabling of the timeline spinlock to protect the irq state in conjunction to the engine's timeline requests, but this is accidental and conflates the spinlock with the irq state. A baffling state of affairs for the reader. Instead, explicitly disable irqs over the critical section, and separate modifying the irq state from the timeline's requests. Suggested-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Although this state (execlists->active and engine->irq_posted) itself is not protected by the engine->timeline spinlock, it does conveniently ensure that irqs are disabled. We can use this to protect our manipulation of the state and so ensure that the next IRQ to arrive sees consistent state and (hopefully) ignores the reset engine. Suggested-by:
-
Chris Wilson authored
After staring hard at sequences like [ 28.199013] systemd-1 2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?] [ 28.199095] systemd-1 2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1 [ 28.199177] systemd-1 2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024 [ 28.199258] systemd-1 2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0 [ 28.199340] gem_eio-829 1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0 [ 28.199421] <idle>-0 2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?] [ 28.199503] <idle>-0 2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1 [ 28.199585] gem_eio-829 1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0 [ 28.199667] gem_eio-829 1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0 [ 28.199749] <idle>-0 2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?] [ 28.199830] <idle>-0 2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1 [ 28.199912] <idle>-0 2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0 [ 28.199994] gem_eio-829 2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?] [ 28.200096] gem_eio-829 2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5 [ 28.200178] gem_eio-829 2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0 [ 28.200260] gem_eio-829 2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id) the conclusion is that the only place where the ports are reset to zero, is from engine->cancel_requests called during i915_gem_set_wedged(). The race is horrible as it results from calling set-wedged on active HW (the GPU reset failed) and as such we need to be careful as the HW state changes beneath us. Fortunately, it's the same scary conditions as affect normal reset, so we can reuse the same machinery to disable state tracking as we clobber it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945Signed-off-by:
-
Ville Syrjälä authored
We have two instances of the code to fill out the header for the aux message. Pull it into a small helper. v2: Rebase due to txbuf[] changes Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222212802.4826-1-ville.syrjala@linux.intel.comReviewed-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Let's try to keep the details on the AKSV stuff concentrated in one place. So move the control bit and +5 data size handling there. v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer() will still load into the registers even though the hardware will ignore it Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: -
Ville Syrjälä authored
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey what it actually does. Signed-off-by:
-
Imre Deak authored
Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may cause pipe FIFO underruns and flickers, so disable FBC on such a config. I tried the followings to work around the issue: - enable each HW work around in ILK_DPFC_CHICKEN - disable each compression algorithm in ILK_DPFC_CONTROL - disable low-power watermarks None of the above got rid of the problem. I haven't found this issue in the Bspec/WA database either. Besides the igt testcase below (yet to be merged) an easy way to reproduce the issue is to enable a plane with FBC and a plane Y-offset not aligned to 4 and then just enable/disable FBC in a loop, keeping the plane enabled. I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's only present on GEN9 and GEN10. v2: (Ville) - Run the test/apply the WA on CNL as well. - Use IS_GEN() instead of INTEL_GEN(). - Fix spelling. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Testcase: igt/kms_plane/plane-clipping-pipe-A-planes Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
In decimal its just a weird big number, while in hex can actually log which engines were requested to be wedged. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
Sagar Arun Kamble authored
GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw loading functions and declarations to separate files intel_huc_fw.c|h like GuC. While at this, do below changes 1. Update kernel-doc comment for intel_*_fw_upload() functions 2. s/huc_ucode_xfer/huc_fw_xfer 3. Introduce intel_huc_fw_init_early() v2: Changed patch to update HuC functions instead of changing guc_fw_upload and update file structure. (Michal Wajdeczko) v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko) Signed-off-by: -
Maarten Lankhorst authored
Moving the check upwards will mean we we no longer have to add planes and connectors manually, because everything is handled correctly by drm_atomic_helper_check_modeset() as intended. [applied with whitespace changes to make sparse happy] Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
