summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gvt
AgeCommit message (Collapse)Author
2019-05-21drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry()Dan Carpenter
"ret" is uninitialized on this path but it should be -EINVAL. Fixes: 930c8dfea4b8 ("drm/i915/gvt: Check if get_next_pt_type() always returns a valid value") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardwareYan Zhao
the vGPU write on TRTTE and 0x4dfc is now write to vreg first. their values all be restored hardware when context switching. Fixes: e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: add 0x4dfc to gen9 save-restore listYan Zhao
0x4dfc is in-context mmio for gen9+, but each vm have different settings need to add it to save-restore list along with other trtt registers Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+Yan Zhao
TRVATTL3PTRDW(0x4de0-0x4de4), TRNULLDETCT(0x4de8), TRINVTILEDETCT(0x4dec), TRTTE(0x4df0), TRVADR(0x4df4) are in-context mmios for gen9+ Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platformYan Zhao
for restore-inhibit context, hardware will not load in-context mmios (engine context part) to hardware, but hardware will save the mmio values in hardware back to context image. So, in order to save correct values of vGPU back to context image, values of vGPU mmios have to be loaded into hardware first for restore-inhibit context. In this patch, the mechanism is applied to all gen9 platform. The reason excluding gen8 platforms is only because of lacking of testing on those platforms. v3: for mocs registers, goto in-context mmios save-restore path for skl platform as well (weinan li) v2: update vreg when scanning indirect context for inhibit context for gen9 Cc: Weinan Li <weinan.z.li@intel.com> Acked-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: emit init breadcrumb for gvt requestWeinan
"To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request." It means all the request which timeline's has_init_breadcrumb is true, then the emit_init_breadcrumb process must have before emitting the real commands, otherwise, the scheduler might get a wrong state of this request during reset. If the request is exactly the guilty one, the scheduler won't terminate it with the wrong state. To avoid this, do emit_init_breadcrumb for all the requests from gvt. v2: cc to stable kernel Fixes: 8547444137ec ("drm/i915: Identify active requests") Cc: stable@vger.kernel.org Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-10Merge tag 'drm-intel-next-fixes-2019-05-09' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190509100109.GA14820@jlahtine-desk.ger.corp.intel.com
2019-05-05drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio listColin Xu
Depends on GEN family and I915_PARAM_HAS_CONTEXT_ISOLATION, Mesa driver will decide whether constant buffer 0 address is relative or absolute, and load GPU initial state by lri to context mmio INSTPM (GEN8) or 0x20D8 (>=GEN9). Mesa Commit fa8a764b62 ("i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.") INSTPM is already added to gen8_engine_mmio_list, but 0x20D8 is missed in gen9_engine_mmio_list. From GVT point of view, different guest could have different context so should switch those mmio accordingly. v2: Update fixes commit ID. Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> (cherry picked from commit 1e8b15a1988ed3c7429402017d589422628cdf47)
2019-04-29drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 ↵Zhao Yakui
MCHBAR to optimize gvt-g boot time" This reverts commit f74a6d9a2c427b6656bc93eacfa6d329ba54d611. BXT needs to access 0x141000-0x1417ff register to obtain the dram info. But after the snapshot range of I915_MCHBAR is refined in f74a6d9a2c, it only initializes the range of 0x144000-0x147fff for VGPU and then causes that the guest GPU can't get the initialized value for dram detection on BXT. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-26drm: prefix header search paths with $(srctree)/Masahiro Yamada
Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf5bc6 ("kbuild: do not drop -I without parameter"). [1]: https://patchwork.kernel.org/patch/9632347/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1553859161-2628-1-git-send-email-yamada.masahiro@socionext.com
2019-04-25drm/i915/gvt: Check if get_next_pt_type() always returns a valid valueAleksei Gimbitskii
According to gtt_type_table[] function get_next_pt_type() may returns GTT_TYPE_INVALID in some cases. To prevent driver to try to create memory page with invalid data type, additional check is added. Signed-off-by: Aleksei Gimbitskii <aleksei.gimbitskii@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-25drm/i915/gvt: Use snprintf() to prevent possible buffer overflow.Aleksei Gimbitskii
For printing the intel_vgpu->id, a buffer with fixed length is allocated on the stack. But if vgpu->id is greater than 6 characters, the buffer overflow will happen. Even the string of the amount of max vgpu is less that the length buffer right now, it's better to replace sprintf() with snprintf(). v2: - Increase the size of the buffer. (Colin Xu) This patch fixed the critical issue #673 reported by klocwork. Signed-off-by: Aleksei Gimbitskii <aleksei.gimbitskii@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-25drm/i915/gvt: Do not copy the uninitialized pointer from fb_infoAleksei Gimbitskii
In the code the memcpy() function copied uninitialized pointer in fb_info to dmabuf_obj->info. Later the pointer in dmabuf_obj->info will be initialized. To make the code aligned with requirements of the klocwork static code analyzer, the uninitialized pointer should be initialized before memcpy(). v2: - Initialize fb_info.obj in vgpu_get_plane_info(). (Colin Xu) This patch fixed the critical issue #632 reported by klockwork. Signed-off-by: Aleksei Gimbitskii <aleksei.gimbitskii@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-25drm/i915/gvt: Remove typedef and let the enumeration starts from zeroAleksei Gimbitskii
Typedef is not recommended in the Linux kernel.The klocwork static code analyzer takes the enumeration as the full range of intel_gvt_gtt_type_t. But the intel_gvt_gtt_type_t will never be used in full range. For example, the GTT_TYPE_INVALID will never be used as an index of an array. Remove the typedef and let the enumeration starts from zero to pass klocwork analysis. This patch fixed the critial issues #483, #551, #665 reported by klockwork. v3: - Remove the typedef and let the enumeration starts from zero. Signed-off-by: Aleksei Gimbitskii <aleksei.gimbitskii@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> CC: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-25drm/i915/gvt: Change fb_info->size from pages to bytesXiong Zhang
fb_info->size is in pages, but some function need bytes when it is as a parameter. Such as: a. intel_gvt_ggtt_validate_range(), according to function definition b. vifio_device_gfx_plane_info->size, according to the comment of its definition So change fb_info->size into bytes. v2: Keep fb_info->size in real size instead of assinging casted page size(zhenyu) v3: obj->size should be page aligned and delete redundant check(zhenyu) Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-24Merge tag 'drm-intel-next-2019-04-17' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - uAPI "Fixes:" patch for the upcoming kernel 5.1, included here too We have an Ack from the media folks (only current user) for this late tweak Cross-subsystem Changes: - ALSA: hda: Fix racy display power access (Takashi, Chris) Driver Changes: - DDI and MIPI-DSI clocks fixes for Icelake (Vandita) - Fix Icelake frequency change/locking (RPS) (Mika) - Temporarily disable ppGTT read-only bit on Icelake (Mika) - Add missing Icelake W/As (Mika) - Enable 12 deep CSB status FIFO on Icelake (Mika) - Inherit more Icelake code for Elkhartlake (Bob, Jani) - Handle catastrophic error on engine reset (Mika) - Shortcut readiness to reset check (Mika) - Regression fix for GEM_BUSY causing us to report a mixed uabi-class request as not busy (Chris) - Revert back to max link rate and lane count on eDP (Jani) - Fix pipe BPP readout for BXT/GLK DSI (Ville) - Set DP min_bpp to 8*3 for non-RGB output formats (Ville) - Enable coarse preemption boundaries for Gen8 (Chris) - Do not enable FEC without DSC (Ville) - Restore correct BXT DDI latency optim setting calculation (Ville) - Always reset context's RING registers to avoid running workload twice during reset (Chris) - Set GPU wedged on driver unload (Janusz) - Consolidate two similar barries from timeline into one (Chris) - Only reset the pinned kernel contexts on resume (Chris) - Wakeref tracking improvements (Chris, Imre) - Lockdep fixes for shrinker interactions (Chris) - Bump ready tasks ahead of busywaits in prep of semaphore use (Chris) - Huge step in splitting display code into fine grained files (Jani) - Refactor the IRQ init/reset macros for code saving (Paulo) - Convert IRQ initialization code to uncore MMIO access (Paulo) - Convert workarounds code to use uncore MMIO access (Chris) - Nuke drm_crtc_state and use intel_atomic_state instead (Manasi) - Update SKL clock-gating WA (Radhakrishna, Ville) - Isolate GuC reset code flow (Chris) - Expose force_dsc_enable through debugfs (Manasi) - Header standalone compile testing framework (Jani) - Code cleanups to reduce driver footprint (Chris) - PSR code fixes and cleanups (Jose) - Sparse and kerneldoc updates (Chris) - Suppress spurious combo PHY B warning (Vile) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418080426.GA6409@jlahtine-desk.ger.corp.intel.com
2019-04-16drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio listColin Xu
According to GFX PRM on 01.org, bit 31:16 of mmio 0x22028 should be masks. Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16drm/i915/gvt: addressed guest GPU hang with HWS index modeXiaolin Zhang
with the introduce of "switch to use HWS indices rather than address", guest GPU hang observed when running workloads which will update the seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang. this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and patch guest GPU HWSP address value to these commands. Fixes: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-16Merge tag 'drm-intel-next-2019-04-04' into gvt-nextZhenyu Wang
Merge back drm-intel-next for engine name definition refinement and 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") that would need gvt fixes to depend on. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-15BackMerge v5.1-rc5 into drm-nextDave Airlie
Need rc5 for udl fix to add udl cleanups on top. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-04-11drm/i915/gvt: Roundup fb->height into tile's height at calucation fb->sizeXiong Zhang
When fb is tiled and fb->height isn't the multiple of tile's height, the format fb->size = fb->stride * fb->height, will get a smaller size than the actual size. As the memory height of tiled fb should be multiple of tile's height. Fixes: 7f1a93b1f1d1 ("drm/i915/gvt: Correct the calculation of plane size") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-08drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt()Chris Wilson
ppgtt_free_all_spt() iterates the radixtree as it is deleting it, forgoing all protection against the leaves being freed in the process (leaving the iter pointing into the void). A minimal fix seems to be to use the available post_shadow_list to decompose the tree into a list prior to destroying the radixtree. Alerted by the sparse warnings: drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/gvt/gtt.c:757:9: expected void **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: got void [noderef] <asn:4> ** drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/gvt/gtt.c:757:9: expected void **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: got void [noderef] <asn:4> ** drivers/gpu/drm/i915/gvt/gtt.c:758:45: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/gvt/gtt.c:758:45: expected void [noderef] <asn:4> **slot drivers/gpu/drm/i915/gvt/gtt.c:758:45: got void **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/gvt/gtt.c:757:9: expected void [noderef] <asn:4> **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: got void **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/gvt/gtt.c:757:9: expected void **slot drivers/gpu/drm/i915/gvt/gtt.c:757:9: got void [noderef] <asn:4> ** This would also have been loudly warning if run through CI for the invalid RCU dereferences. Fixes: b6c126a39345 ("drm/i915/gvt: Manage shadow pages with radix tree") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-08drm/i915/gvt: Annotate iomem usageChris Wilson
Fix the sparse warning for blithely using iomem with normal memcpy: drivers/gpu/drm/i915/gvt/kvmgt.c:916:21: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/gvt/kvmgt.c:916:21: expected void *aperture_va drivers/gpu/drm/i915/gvt/kvmgt.c:916:21: got void [noderef] <asn:2> * drivers/gpu/drm/i915/gvt/kvmgt.c:927:26: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/gvt/kvmgt.c:927:26: expected void [noderef] <asn:2> *vaddr drivers/gpu/drm/i915/gvt/kvmgt.c:927:26: got void *aperture_va Fixes: d480b28a41a6 ("drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-04drm/i915/gvt: Fix kerneldoc typo for intel_vgpu_emulate_hotplugChris Wilson
drivers/gpu/drm/i915/gvt/display.c:457: warning: Function parameter or member 'connected' not described in 'intel_vgpu_emulate_hotplug' drivers/gpu/drm/i915/gvt/display.c:457: warning: Excess function parameter 'conncted' description in 'intel_vgpu_emulate_hotplug' Fixes: 1ca20f33df42 ("drm/i915/gvt: add hotplug emulation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Hang Yuan <hang.yuan@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-04drm/i915/gvt: Correct the calculation of plane sizeXiong Zhang
stride isn't in unit of pixel, it is bytes, so calculation of plane size doesn't need to multiple bpp. Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-02drm/i915: Move intel_engine_mask_t around for use by i915_request_types.hChris Wilson
We want to use intel_engine_mask_t inside i915_request.h, which means extracting it from the general header file mess and placing it inside a types.h. A knock on effect is that the compiler wants to warn about type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare for the worst. v2: Use intel_engine_mask_t consistently v3: Move I915_NUM_ENGINES to its natural home at the end of the enum Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2019-03-29drm/i915/gvt: Enable async flip on plane surface mmio writesColin Xu
According to Intel GFX PRM on 01.org, plane surface address can be updated synchronously or asynchronously. Synchronous flip will hold plane surface address update to start of next vsync, which is current implementation. Asynchronous flip will update the address as soon as possible. Without async flip, some 3D application could not reach better performance and the maximum performance is no higher than vsync frequency. The patch enables the async flip on plane surface address mmio update, and increment flip count correctly. With async flip enabled, some 3D applications have significant performance improvement. i.e. 3DMark Ice Storm has a 300%~400% increment on score. v2: Use bit operation definition for flip mode. (zhenyu) Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-29drm/i915/gvt: Enable synchronous flip on handling MI_DISPLAY_FLIPColin Xu
According to Intel GFX PRM on 01.org, the MI_DISPLAY_FLIP command can either request display plane flip synchronously or asynchronously. In synchronous flip, flip will be hold until next vsync, which is not implemented yet in GVT. In asynchronous flip, flip will happen immediately, which is current implementation. The patch enables the sync flip on handling MI_DISPLAY_FLIP, and increment flip count correctly by only increment on primary plane. v2: Use bit operation definition for flip mode. (zhenyu) Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-29drm/i915/gvt: Add macro define for mmio 0x50080 and gvt flip eventColin Xu
Add SKL_FLIP_EVENT to address into intel_gvt_event_type for primary and sprite0 plane flip event. Add macro to address REG_50080 offset. v2: Add bit operation definition for flip mode. (zhenyu) Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-29drm/i915/gvt: replaced register address with nameXiaolin Zhang
in init_skil_mmio_info, replaced register address with the known name from i915_reg.h definition to improve code readbility. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-29drm/i915/gvt: do not let pin count of shadow mm go negativeYan Zhao
shadow mm's pin count got increased in workload preparation phase, which is after workload scanning. it will get decreased in complete_current_workload() anyway after workload completion. Sometimes, if a workload meets a scanning error, its shadow mm pin count will not get increased but will get decreased in the end. This patch lets shadow mm's pin count not go below 0. Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Cc: zhenyuw@linux.intel.com Cc: stable@vger.kernel.org #4.14+ Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-29drm/i915/gvt: do not deliver a workload if its creation failsYan Zhao
in workload creation routine, if any failure occurs, do not queue this workload for delivery. if this failure is fatal, enter into failsafe mode. Fixes: 6d76303553ba ("drm/i915/gvt: Move common vGPU workload creation into scheduler.c") Cc: stable@vger.kernel.org #4.19+ Cc: zhenyuw@linux.intel.com Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-26drm/i915: take a reference to uncore in the engine and use itDaniele Ceraolo Spurio
A few advantages: - Prepares us for the planned split of display uncore from GT uncore - Improves our engine-centric view of the world in the engine code and allows us to avoid jumping back to dev_priv. - Allows us to wrap accesses to engine register in nice macros that automatically pick the right mmio base. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-10-daniele.ceraolospurio@intel.com
2019-03-26drm/i915: switch intel_uncore_forcewake_for_reg to intel_uncoreDaniele Ceraolo Spurio
The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-7-daniele.ceraolospurio@intel.com
2019-03-21Merge tag 'gvt-fixes-2019-03-21' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-fixes gvt-fixes-2019-03-21 - Fix MI_FLUSH_DW cmd parser on index check (Zhenyu) - Fix Windows guest font render error (Colin) - Fix unexpected workload submission for inactive vGPU (Weinan) - Fix incorrect workload submission in error path (Zhenyu) - Fix warning for shadow ppgtt mm reclaim list walk with locking (Zhenyu) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190321035018.GF10798@zhen-hp.sh.intel.com
2019-03-20drm/i915: use intel_uncore for all forcewake get/putDaniele Ceraolo Spurio
Now that the internal code all works on intel_uncore, flip the external-facing interface. v2: fix GVT. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-4-daniele.ceraolospurio@intel.com
2019-03-15drm/i915/gtt: Rename i915_vm_is_48b to i915_vm_is_4lvlChris Wilson
Large ppGTT are differentiated by the requirement to go to four levels to address more than 32b. Given the introduction of more 4 level ppGTT with different sizes of addressable bits, rename i915_vm_is_48b() to better reflect the commonality of using 4 levels. Based on a patch by Bob Paauwe. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314223839.28258-4-chris@chris-wilson.co.uk
2019-03-15drm/i915: Mark up vGPU support for full-ppgttChris Wilson
For compatibility reasons, we only care if the vGPU host provides support for full-ppgtt. This is independent of the addressable memory size, so remove the conflation of 48b from the capability name. Based on a patch by Bob Paauwe. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314223839.28258-1-chris@chris-wilson.co.uk
2019-03-11drm/i915/gvt: remove the unused sregYan Zhao
code cleanup. sreg is not used now. remove it for code cleanness. v3: remove unnecessary array_size in vreg's memory allocation (min he) v2: do not allocate memory for sreg. (min he) Reviewed-by: He, Min <min.he@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-08drm/i915: Move over to intel_context_lookup()Chris Wilson
In preparation for an ever growing number of engines and so ever increasing static array of HW contexts within the GEM context, move the array over to an rbtree, allocated upon first use. Unfortunately, this imposes an rbtree lookup at a few frequent callsites, but we should be able to mitigate those by moving over to using the HW context as our primary type and so only incur the lookup on the boundary with the user GEM context and engines. v2: Check for no HW context in guc_stage_desc_init Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308132522.21573-4-chris@chris-wilson.co.uk
2019-03-05drm/i915: Store the BIT(engine->id) as the engine's maskChris Wilson
In the next patch, we are introducing a broad virtual engine to encompass multiple physical engines, losing the 1:1 nature of BIT(engine->id). To reflect the broader set of engines implied by the virtual instance, lets store the full bitmask. v2: Use intel_engine_mask_t (s/ring_mask/engine_mask/) v3: Tvrtko voted for moah churn so teach everyone to not mention ring and use $class$instance throughout. v4: Comment upon the disparity in bspec for using VCS1,VCS2 in gen8 and VCS[0-4] in later gen. We opt to keep the code consistent and use 0-index naming throughout. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305180332.30900-1-chris@chris-wilson.co.uk
2019-03-04drm/i915/gvt: Add mutual lock for ppgtt mm LRU listZhenyu Wang
This adds mutex to guard against update of global ppgtt mm LRU list. To resolve error found as below warning. [73130.012162] ------------[ cut here ]------------ [73130.012168] list_add corruption. prev->next should be next (ffff995f970cca50), but was 0000000000000000. (prev=ffff995f0dc5bdf8). [73130.012181] WARNING: CPU: 3 PID: 82 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 [73130.012183] Modules linked in: btrfs(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) dm_mod(E) kvmgt(E) fuse(E) xt_addrtype(E) nft_compat(E) xt_conntrack(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) libcrc32c(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) devlink(E) nf_tables(E) nfnetlink(E) loop(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) mei_me(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) intel_cstate(E) intel_uncore(E) mei(E) intel_pch_thermal(E) intel_rapl_perf(E) pcspkr(E) iTCO_wdt(E) iTCO_vendor_support(E) idma64(E) sg(E) virt_dma(E) acpi_pad(E) evdev(E) binfmt_misc(E) ip_tables(E) x_tables(E) ipv6(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) xhci_pci(E) sdhci_pci(E) cqhci(E) intel_lpss_pci(E) intel_lpss(E) crc32c_intel(E) xhci_hcd(E) sdhci(E) i2c_i801(E) e1000e(E) mmc_core(E) [73130.012218] ptp(E) pps_core(E) usbcore(E) mfd_core(E) sd_mod(E) fan(E) thermal(E) [73130.012227] CPU: 3 PID: 82 Comm: gvt workload 0 Tainted: G W E 5.0.0-rc7-staging-190226+ #282 [73130.012228] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0039.2016.0316.1747 03/16/2016 [73130.012232] RIP: 0010:__list_add_valid+0x4d/0x70 [73130.012234] Code: c3 48 89 d1 48 c7 c7 e0 82 91 bb 48 89 c2 e8 44 8a cc ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 30 83 91 bb e8 2d 8a cc ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 80 83 91 bb e8 [73130.012236] RSP: 0018:ffffa4924107fdd0 EFLAGS: 00010286 [73130.012238] RAX: 0000000000000000 RBX: ffff995d8a5ccf00 RCX: 0000000000000006 [73130.012240] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff995faad96680 [73130.012241] RBP: 0000000000000000 R08: 0000000000213a28 R09: 0000000000000084 [73130.012243] R10: 0000000000000000 R11: ffffa4924107fc70 R12: ffff995d8a5ccf78 [73130.012245] R13: ffff995f970c8000 R14: ffff995f0dc5bdf8 R15: ffff995f970cca50 [73130.012247] FS: 0000000000000000(0000) GS:ffff995faad80000(0000) knlGS:0000000000000000 [73130.012249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [73130.012250] CR2: 00000222e1891000 CR3: 0000000116848002 CR4: 00000000003626e0 [73130.012252] Call Trace: [73130.012258] intel_vgpu_pin_mm+0x7a/0xa0 [73130.012262] workload_thread+0x683/0x12a0 [73130.012266] ? do_wait_intr_irq+0xb0/0xb0 [73130.012269] ? finish_wait+0x80/0x80 [73130.012271] ? intel_vgpu_clean_workloads+0x110/0x110 [73130.012274] kthread+0x116/0x130 [73130.012276] ? kthread_bind+0x30/0x30 [73130.012280] ret_from_fork+0x35/0x40 [73130.012285] WARNING: CPU: 3 PID: 82 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 [73130.012286] ---[ end trace 458a2e792eec21c0 ]--- v2: - simplify lock handling Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-04drm/i915/gvt: Only assign ppgtt root at dispatch timeZhenyu Wang
This moves ppgtt root hook out of scan and shadow function, as it's only required at dispatch time. Also make sure this checks against shadow mm to be ready, otherwise bail to fail earlier. Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-01drm/i915/gvt: Don't submit request for error workload dispatchZhenyu Wang
As vGPU shadow ctx is loaded with guest context state, arbitrarily submitting request in error workload dispatch path would cause trouble. So don't try to submit in error path now like in previous code. This is to fix VM failure when GPU hang happens. Fixes: f0e994372518 ("drm/i915/gvt: Fix workload request allocation before request add") Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-03-01drm/i915/gvt: stop scheduling workload when vgpu is inactiveWeinan Li
There is one corner case that workload_thread may pick and dispatch one workload of vgpu after it's already deactivated. Below is the scenario: 1. deactive_vgpu got the vgpu_lock, it found pending workload was submitted, then it released the vgpu_lock and wait for vgpu idle. 2. before deactive_vgpu got the vgpu_lock back, workload_thread might pick one new valid workload, then it was blocked by the vgpu_lock. 3. deactive_vgpu got the vgpu_lock again, finished the last processes of deactivating, then release the vgpu_lock. 4. workload_thread got the vgpu_lock, then it will try to dispatch the fetched workload. It's not expected one workload of deactivated vgpu is dispatched. The solution is to add condition check of the vgpu's active flag and stop to schedule when it's inactive. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-28drm/i915: Make object/vma allocation caches globalChris Wilson
As our allocations are not device specific, we can move our slab caches to a global scope. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228102035.5857-2-chris@chris-wilson.co.uk
2019-02-22drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio listColin Xu
Depends on GEN family and I915_PARAM_HAS_CONTEXT_ISOLATION, Mesa driver will decide whether constant buffer 0 address is relative or absolute, and load GPU initial state by lri to context mmio INSTPM (GEN8) or 0x20D8 (>=GEN9). Mesa Commit fa8a764b62 ("i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.") INSTPM is already added to gen8_engine_mmio_list, but 0x20D8 is missed in gen9_engine_mmio_list. From GVT point of view, different guest could have different context so should switch those mmio accordingly. v2: Update fixes commit ID. Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-21drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index checkZhenyu Wang
When MI_FLUSH_DW post write hw status page in index mode, the index value is in dword step and turned into address offset in cmd dword1. As status page size is 4K, so can't exceed that. This fixed upper bound check in cmd parser code which incorrectly stopped VM for reason of invalid MI_FLUSH_DW write index. v2: - Fix upper bound as 4K page size because index value is address offset. Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner") Cc: stable@vger.kernel.org # v4.10+ Cc: "Zhao, Yan Y" <yan.y.zhao@intel.com> Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-20drm/i915/gvt: Refine the combined intel_vgpu_oos_page struct to save memoryZhao Yakui
The intel_vgpu_oos_page uses the combined structure, which embeds the tracked page. As it is allocated by kmalloc, the size(4140) is aligned to 8192. The 8192 oos_pages will waste about 32M memory. So the tracked page is split from the intel_vgpu_oos_page. And this will help to assure that the access of tracked page is cache aligned. Another minor change is that it doesn't need to be cleared to zero as it is writen firstly when one page is added to oos_page list. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-20drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g ↵Zhao Yakui
boot time Currently it will take the snapshot of the MCHBAR registers for gvt-g initialization so that it can be used for guest vgpu. And it will cover from 0x140000 to 0x17ffff. In fact based on the HW spec most of them are meanlingless and some time is wasted to read these register. Only the range of 0x144000 to 0x147fff contains the valid definition. So the range of capturing I915 MCHBAR register is refined, which helps to optimize the gvt-g boot time. V1->V2: Move the register definition into reg.h Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 23:08:24 +0000