summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gvt
AgeCommit message (Collapse)AuthorFilesLines
2019-08-06drm/i915/gvt: fix incorrect cache entry for guest page mappingXiaolin Zhang1-0/+12
commit 7366aeb77cd840f3edea02c65065d40affaa7f45 upstream. GPU hang observed during the guest OCL conformance test which is caused by THP GTT feature used durning the test. It was observed the same GFN with different size (4K and 2M) requested from the guest in GVT. So during the guest page dma map stage, it is required to unmap first with orginal size and then remap again with requested size. Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support") Cc: stable@vger.kernel.org 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/i915/gvt: Initialize intel_gvt_gtt_entry in stackTina Zhang1-2/+4
commit 387a4c2b55291b37e245c840813bd8a8bd06ed49 upstream. Stack struct intel_gvt_gtt_entry value needs to be initialized before being used, as the fields may contain garbage values. W/o this patch, set_ggtt_entry prints: ------------------------------------- 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0x9bed8000ffffe900 0x9bed8000 is the stack grabage. W/ this patch, set_ggtt_entry prints: ------------------------------------ 274.046840: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 274.046846: set_ggtt_entry: vgpu1:set ggtt entry 0xe55df001 274.046852: set_ggtt_entry: vgpu1:set ggtt entry 0xffffe900 v2: - Initialize during declaration. (Zhenyu) Fixes: 7598e8700e9a ("drm/i915/gvt: Missed to cancel dma map for ggtt entries") Cc: stable@vger.kernel.org # v4.20+ Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17drm/i915/gvt: do not deliver a workload if its creation failsYan Zhao1-2/+3
commit dade58ed5af6365ac50ff4259c2a0bf31219e285 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17drm/i915/gvt: do not let pin count of shadow mm go negativeYan Zhao1-1/+1
[ Upstream commit 663a50ceac75c2208d2ad95365bc8382fd42f44d ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-03drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index checkZhenyu Wang1-1/+1
commit 13bcb80b7ee79431fce361e060611134cb19e209 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22drm/i915/gvt: Fix mmap range checkZhenyu Wang1-2/+12
commit 51b00d8509dc69c98740da2ad07308b630d3eb7d upstream. This is to fix missed mmap range check on vGPU bar2 region and only allow to map vGPU allocated GMADDR range, which means user space should support sparse mmap to get proper offset for mmap vGPU aperture. And this takes care of actual pgoff in mmap request as original code always does from beginning of vGPU aperture. Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT") Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com> Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com> Cc: stable@vger.kernel.org # v4.10+ Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-19drm/i915/gvt: Fix tiled memory decoding bug on BDWTina Zhang1-1/+1
commit a40fa231bb64b33e2cd54cf8ef44a9f89875fa11 upstream. Commit b244ffa15c8b ("drm/i915/gvt: Fix drm_format_mod value for vGPU plane") introduced a regression issue to the tiled memory decoding on BDW. This patch can fix this issue. Here is the issue detail: https://github.com/intel/gvt-linux/issues/61 v1->v2: - Refine the commit message. (Zhenyu) Fixes: b244ffa15c8b("drm/i915/gvt: Fix drm_format_mod value for vGPU plane") Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: stable@vger.kernel.org # v4.19+ Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-21drm/i915: Compare user's 64b GTT offset even on 32bChris Wilson1-1/+0
commit 085603287452fc96376ed4888bf29f8c095d2b40 upstream. Beware mixing unsigned long constants and 64b values, as on 32b the constant will be zero extended and discard the high 32b when used as a mask! Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108282 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181025091823.20571-2-chris@chris-wilson.co.uk (cherry picked from commit 6fc4e48f9ed46e9adff236a0c350074aafa3b7fa) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-18drm/i915/gvt: clear ggtt entries when destroy vgpuZhipeng Gong1-0/+1
When one vgpu is destroyed, its ggtt entries are not cleared. This patch clears ggtt entries to avoid information leak. v2: add 'Fixes' tag (Zhenyu) Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com> Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-09-18drm/i915/gvt: request srcu_read_lock before checking if one gfn is validWeinan Li1-1/+6
Fix the suspicious RCU usage issue in intel_vgpu_emulate_mmio_write. Here need to request the srcu read lock of kvm->srcu before doing gfn_to_memslot(). The detailed log is as below: [ 218.710688] ============================= [ 218.710690] WARNING: suspicious RCU usage [ 218.710693] 4.14.15-dd+ #314 Tainted: G U [ 218.710695] ----------------------------- [ 218.710697] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage! [ 218.710699] other info that might help us debug this: [ 218.710702] rcu_scheduler_active = 2, debug_locks = 1 [ 218.710704] 1 lock held by qemu-system-x86/2144: [ 218.710706] #0: (&gvt->lock){+.+.}, at: [<ffffffff816a1eea>] intel_vgpu_emulate_mmio_write+0x5a/0x2d0 [ 218.710721] stack backtrace: [ 218.710724] CPU: 0 PID: 2144 Comm: qemu-system-x86 Tainted: G U 4.14.15-dd+ #314 [ 218.710727] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015 [ 218.710729] Call Trace: [ 218.710734] dump_stack+0x7c/0xb3 [ 218.710739] gfn_to_memslot+0x15f/0x170 [ 218.710743] kvm_is_visible_gfn+0xa/0x30 [ 218.710746] intel_vgpu_emulate_gtt_mmio_write+0x267/0x3c0 [ 218.710751] ? __mutex_unlock_slowpath+0x3b/0x260 [ 218.710754] intel_vgpu_emulate_mmio_write+0x182/0x2d0 [ 218.710759] intel_vgpu_rw+0xba/0x170 [kvmgt] [ 218.710763] intel_vgpu_write+0x14d/0x1a0 [kvmgt] [ 218.710767] __vfs_write+0x23/0x130 [ 218.710770] vfs_write+0xb0/0x1b0 [ 218.710774] SyS_pwrite64+0x73/0x90 [ 218.710777] entry_SYSCALL_64_fastpath+0x25/0x9c [ 218.710780] RIP: 0033:0x7f33e8a91da3 [ 218.710783] RSP: 002b:00007f33dddc8700 EFLAGS: 00000293 v2: add 'Fixes' tag, refine log format.(Zhenyu) Fixes: cc753fbe1ac4 ("drm/i915/gvt: validate gfn before set shadow page") 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>
2018-09-18drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handlerColin Xu1-0/+1
Host prints lots of untracked MMIO at 0x4653c when creating linux guest. "gvt: vgpu 2: untracked MMIO 0004653c len 4" GEN9_CLKGATE_DIS_4 (0x4653c) is accessed by i915 for gmbus clockgating. However vgpu doesn't support any clockgating powergating operations on related mmio access trap so need add it to default handler. GEN9_CLKGATE_DIS_4 is accessed in bxt_gmbus_clock_gating() which only applies to GEN9_LP so doens't show the warning on other platforms. The solution is to add it to default handler init_bxt_mmio_info(). Reviewed-by: He, Min <min.he@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-09-18drm/i915/gvt: Init PHY related registers for BXTColin Xu1-0/+28
Recent patch fixed the call trace "ERROR Port B enabled but PHY powered down? (PHY_CTL 00000000)". but introduced another similar call trace shown as: "ERROR Port C enabled but PHY powered down? (PHY_CTL 00000200)". The call trace will appear when host and guest enabled different ports, i.e. host using PORT C or neither PORT is enabled, while guest is always using PORT B as simulated by gvt. The issue is actually covered previously before the commit and reverals now when the commit do the right thing. On BXT, some PHY registers are initialized by vbios, before i915 loaded. Later i915 will re-program some, or skip some based on the implementation. The initialized mmio for guest i915 is done by gvt, based on the snapshot taken from host. If host and guest have different PORT enabled, some DPIO PHY mmios that gvt initialized for guest i915 will not match the simualted monitor for guest, which leads to guest i915 print the calltrace when it's trying to enable PHY and PORT. The solution is to init these DPIO PHY registers to default value, then guest i915 will program them to reasonable value based on the default powerwell table and enabled PORT. Together with the old patch, all similar call trace in guest kernel on BXT can be resolved. v2: Move PHY register init to intel_vgpu_reset_mmio (Min) v3: Do not delete empty line in issue fix patch. (zhenyu) Fixes: c8ab5ac30ccc ("drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY") Reviewed-by: He, Min <min.he@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-09-06drm/i915/gvt: Fix the incorrect length of child_device_config issueWeinan Li1-11/+9
GVT-g emualte the opregion for guest with bdb version as '186' which child_device_config length should be '33'. v2: split into 2 patch. 1st for issue fix, 2nd for code clean up.(Zhenyu) v3: add fixes tag.(Zhenyu) Fixes: 4023f301d28f ("drm/i915/gvt: opregion virtualization for win") CC: Xiaolin Zhang <xiaolin.zhang@intel.com> Reviewed-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-09-04drm/i915/gvt: Fix life cycle reference on KVM mmZhenyu Wang1-2/+8
Handle guest mm access life cycle properly with mmget()/mmput(). As noted by Linus, use_mm() depends on valid live page table but KVM's mmgrab() doesn't guarantee that. As vGPU usage depends on guest VM life cycle, need to make sure to use mmget()/mmput() to guarantee VM address access. v3: fix build v2: v1 caused a weird dependence issue which failed for vfio device release, which result invalid mdev vgpu and kvm state without proper release taken. This trys to put right reference around VM address space access instead. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-09-03drm/i915/gvt: Give new born vGPU higher scheduling chanceZhenyu Wang1-7/+27
This trys to give new born vGPU with higher scheduling chance not only with adding to sched list head and also have higher priority for workload sched for 2 seconds after starting to schedule it. In order for fast GPU execution during VM boot, and ensure guest driver setup with required state given in time. This fixes recent failure seen on one VM with multiple linux VMs running on kernel with commit 2621cefaa42b3("drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup"), which had shorter setup timeout that caused context state init failed. v2: change to 2s for higher scheduling period Cc: Yuan Hang <hang.yuan@intel.com> Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-30drm/i915/gvt: Fix drm_format_mod value for vGPU planeZhenyu Wang3-11/+29
Physical plane's tiling mode value is given directly as drm_format_mod for plane query, which is not correct fourcc code. Fix it by using correct intel tiling fourcc mod definition. Current qemu seems also doesn't correctly utilize drm_format_mod for plane object setting. Anyway this is required to fix the usage. v3: use DRM_FORMAT_MOD_LINEAR, fix comment v2: Fix missed old 'tiled' use for stride calculation Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Cc: Tina Zhang <tina.zhang@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.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>
2018-08-30drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in stop_scheduleHang Yuan2-2/+3
pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915 device is not active. When stop vgpu schedule, the device may be inactive. So need to move runtime_pm_get out of spin_lock/unlock. Fixes: b24881e0b0b6("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio Cc: <stable@vger.kernel.org> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-30drm/i915/gvt: Handle GEN9_WM_CHICKEN3 with F_CMD_ACCESS.Colin Xu1-1/+3
Recent patch introduce strict check on scanning cmd: Commit 8d458ea0ec33 ("drm/i915/gvt: return error on cmd access") Before 8d458ea0ec33, if cmd_reg_handler() checks that a cmd access a mmio that not marked as F_CMD_ACCESS, it simply returns 0 and log an error. Now it will return -EBADRQC which will cause the workload fail to submit. On BXT, i915 applies WaClearHIZ_WM_CHICKEN3 which will program GEN9_WM_CHICKEN3 by LRI when init wa ctx. If it has no F_CMD_ACCESS flag, vgpu will fail to start. Also add F_MODE_MASK since it's mode mask reg. v2: Refresh commit message to elaborate issue symptom in detail. v3: Make SKL_PLUS share same handling since GEN9_WM_CHICKEN3 should be F_CMD_ACCESS from HW aspect. (yan, zhenyu) Signed-off-by: Colin Xu <colin.xu@intel.com> Acked-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-30drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILYColin Xu1-3/+9
Guest kernel will write to BXT_PHY_CTL_FAMILY to reset DDI PHY and pull BXT_PHY_CTL to check PHY status. Previous handling will set/reset BXT_PHY_CTL of all PHYs at same time on receiving vreg write to some BXT_PHY_CTL_FAMILY. If some BXT_PHY_CTL is already enabled, following reset to another BXT_PHY_CTL_FAMILY will clear the enabled BXT_PHY_CTL, which result in guest kernel print: ----------------------------------- [drm:intel_ddi_get_hw_state [i915]] *ERROR* Port B enabled but PHY powered down? (PHY_CTL 00000000) ----------------------------------- The correct handling should operate BXT_PHY_CTL_FAMILY and BXT_PHY_CTL on the same DDI. v2: Use correct reg define. The naming looks confusing, however current i915_reg.h bind DPIO_PHY0 to _PHY_CTL_FAMILY_DDI and bind DPIO_PHY1 to _PHY_CTL_FAMILY_EDP, pairing to _BXT_PHY_CTL_DDI_A and _BXT_PHY_CTL_DDI_B respectively. v3: v2 incorrectly map _PHY_CTL_FAMILY_EDP to _BXT_PHY_CTL_DDI_A. BXT_PHY_CTL() looks up DDI using PORTx but not PHYx. Based on DPIO_PHY to DDI mapping, make correct vreg handle to BXT_PHY_CTL on receiving vreg write to BXT_PHY_CTL_FAMILY. (He, Min) Current mapping according to bxt_power_wells: dpio-common-a: >>> DPIO_PHY1 >>> BXT_DPIO_CMN_A_POWER_DOMAINS >>> POWER_DOMAIN_PORT_DDI_A_LANES >>> PORT_A dpio-common-bc: >>> DPIO_PHY0 >>> BXT_DPIO_CMN_BC_POWER_DOMAINS >>> POWER_DOMAIN_PORT_DDI_B_LANES | POWER_DOMAIN_PORT_DDI_C_LANES >>> PORT_B or PORT_C Signed-off-by: Colin Xu <colin.xu@intel.com> Reviewed-by: He, Min <min.he@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-30drm/i915/gvt: emulate gen9 dbuf ctl register accessXiaolin Zhang1-2/+15
there is below call track at boot time when booting guest with kabylake vgpu with specifal configuration and this try to fix it. [drm:gen9_dbuf_enable [i915]] *ERROR* DBuf power enable timeout ------------[ cut here ]------------ WARNING: gen9_dc_off_power_well_enable+0x224/0x230 [i915] Unexpected DBuf power power state (0x8000000a) Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: [<ffffffff99d24408>] dump_stack+0x19/0x1b [<ffffffff996926d8>] __warn+0xd8/0x100 [<ffffffff9969275f>] warn_slowpath_fmt+0x5f/0x80 [<ffffffffc07bbae4>] gen9_dc_off_power_well_enable+0x224/0x230 [i915] [<ffffffffc07ba9d2>] intel_power_well_enable+0x42/0x50 [i915] [<ffffffffc07baa6a>] __intel_display_power_get_domain+0x8a/0xb0 [i915] [<ffffffffc07bdb93>] intel_display_power_get+0x33/0x50 [i915] [<ffffffffc07bdf95>] intel_display_set_init_power+0x45/0x50 [i915] [<ffffffffc07be003>] intel_power_domains_init_hw+0x63/0x8a0 [i915] [<ffffffffc07995c3>] i915_driver_load+0xae3/0x1760 [i915] [<ffffffff99bd6580>] ? nvmem_register+0x500/0x500 [<ffffffffc07a476c>] i915_pci_probe+0x2c/0x50 [i915] [<ffffffff9999cfea>] local_pci_probe+0x4a/0xb0 [<ffffffff9999e729>] pci_device_probe+0x109/0x160 [<ffffffff99a79aa5>] driver_probe_device+0xc5/0x3e0 [<ffffffff99a79ea3>] __driver_attach+0x93/0xa0 [<ffffffff99a79e10>] ? __device_attach+0x50/0x50 [<ffffffff99a77645>] bus_for_each_dev+0x75/0xc0 [<ffffffff99a7941e>] driver_attach+0x1e/0x20 [<ffffffff99a78ec0>] bus_add_driver+0x200/0x2d0 [<ffffffff99a7a534>] driver_register+0x64/0xf0 [<ffffffff9999df65>] __pci_register_driver+0xa5/0xc0 [<ffffffffc0929000>] ? 0xffffffffc0928fff [<ffffffffc0929059>] i915_init+0x59/0x5c [i915] [<ffffffff9960210a>] do_one_initcall+0xba/0x240 [<ffffffff9971108c>] load_module+0x272c/0x2bc0 [<ffffffff9997b990>] ? ddebug_proc_write+0xf0/0xf0 [<ffffffff997115e5>] SyS_init_module+0xc5/0x110 [<ffffffff99d36795>] system_call_fastpath+0x1c/0x21 Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()Yi Wang1-2/+6
The 'sparse' variable may leak when return in function intel_vgpu_ioctl(), and this patch fix this. Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/gvt: Off by one in intel_vgpu_write_fence()Dan Carpenter1-1/+1
The > should be >= here so that we don't read one element beyond the end of the array. Fixes: 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/kvmgt: Fix potential Spectre v1Gustavo A. R. Silva1-1/+8
info.index can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn: potential spectre issue 'vgpu->vdev.region' [r] Fix this by sanitizing info.index before indirectly using it to index vgpu->vdev.region Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/gvt: return error on cmd accessZhao Yan1-1/+1
If a register is not cmd accessible, should not just print error message. Return error here so as not to deliver this cmd. v2: return -EBADRQC to align with return value elsewhere. (kevin tian) Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/gvt: initialize dmabuf mutex in vgpu_createHang Yuan2-1/+1
Currently, the mutex used in GVT dmabuf support is not initialized until vgpu device is opened. If one vgpu device is opened and then removed, the mutex will be used in vgpu remove operation without initialization. This patch initializes the mutex in vgpu create operation to avoid the problem. Fixes: e546e281d33d("drm/i915/gvt: Dmabuf support for GVT-g") Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-14drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_deviceHang Yuan1-8/+6
Create one vGPU and then unbind IGD device from i915 driver. The following oops will happen. This patch will free vgpu resource first and then gvt resource to remove these oops. BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 PGD 80000003c9d2c067 P4D 80000003c9d2c067 PUD 3c817c067 P MD 0 Oops: 0002 [#1] SMP PTI RIP: 0010:down_write+0x1b/0x40 Call Trace: debugfs_remove_recursive+0x46/0x1a0 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [i915] intel_gvt_destroy_vgpu+0x2d/0xf0 [i915] intel_vgpu_remove+0x2c/0x30 [kvmgt] mdev_device_remove_ops+0x23/0x50 [mdev] mdev_device_remove+0xdb/0x190 [mdev] mdev_device_remove+0x190/0x190 [mdev] device_for_each_child+0x47/0x90 mdev_unregister_device+0xd5/0x120 [mdev] intel_gvt_clean_device+0x91/0x120 [i915] i915_driver_unload+0x9d/0x120 [i915] i915_pci_remove+0x15/0x20 [i915] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x157/0x230 unbind_store+0xfc/0x150 kernfs_fop_write+0x10f/0x180 __vfs_write+0x36/0x180 ? common_file_perm+0x41/0x130 ? _cond_resched+0x16/0x40 vfs_write+0xb3/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x55/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: unable to handle kernel NULL pointer dereference at 0 000000000000038 PGD 8000000405bce067 P4D 8000000405bce067 PUD 405bcd067 PM D 0 Oops: 0000 [#1] SMP PTI RIP: 0010:hrtimer_active+0x5/0x40 Call Trace: hrtimer_try_to_cancel+0x25/0x120 ? tbs_sched_clean_vgpu+0x1f/0x50 [i915] hrtimer_cancel+0x15/0x20 intel_gvt_destroy_vgpu+0x4c/0xf0 [i915] intel_vgpu_remove+0x2c/0x30 [kvmgt] mdev_device_remove_ops+0x23/0x50 [mdev] mdev_device_remove+0xdb/0x190 [mdev] ? mdev_device_remove+0x190/0x190 [mdev] device_for_each_child+0x47/0x90 mdev_unregister_device+0xd5/0x120 [mdev] intel_gvt_clean_device+0x89/0x120 [i915] i915_driver_unload+0x9d/0x120 [i915] i915_pci_remove+0x15/0x20 [i915] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x157/0x230 unbind_store+0xfc/0x150 kernfs_fop_write+0x10f/0x180 __vfs_write+0x36/0x180 ? common_file_perm+0x41/0x130 ? _cond_resched+0x16/0x40 vfs_write+0xb3/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x55/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: bc7b0be316ae("drm/i915/gvt: Add basic debugfs infrastructure") Fixes: afe04fbe6c52("drm/i915/gvt: create an idle vGPU") Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-13drm/i915/gvt: free workload in vgpu releaseHang Yuan6-7/+32
Some workloads may be prepared in vgpu's queue but not be scheduled to run yet. If vgpu is released at this time, they will not be freed in workload complete callback and so need to be freed in vgpu release operation. Add new vgpu_release operation in gvt_ops to stop vgpu and release runtime resources. gvt_ops vgpu_deactivate operation will only stop vgpu. v2: add new gvt ops to clean vgpu running status (Xiong Zhang) Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-07drm/i915/kvmgt: fix an error code in gvt_dma_map_page()Dan Carpenter1-3/+3
The dma_mapping_error() returns true on error but we want to return -ENOMEM here. Fixes: 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-06drm/i915/kvmgt: Fix compilation errorMichał Winiarski1-6/+0
gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality: commit 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages") And yet, part of it was reintroduced in: commit 39b4cbadb9a9 ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages") Causing kvmgt part to no longer build. Let's remove it. Reported-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com (cherry picked from commit 4eaf317a60fbea0555b936035002ca9bd9b9105d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-30BackMerge v4.18-rc7 into drm-nextDave Airlie8-4/+144
rmk requested this for armada and I think we've had a few conflicts build up. Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-07-20Merge tag 'drm-intel-next-2018-07-19' of ↵Dave Airlie8-94/+517
git://anongit.freedesktop.org/drm/drm-intel into drm-next On GEM side: - GuC related fixes (Chris, Michal) - GTT read-only pages support (Jon, Chris) - More selftests fixes (Chris) - More GPU reset improvements (Chris) - Flush caches after GGTT writes (Chris) - Handle recursive shrinker for vma->last_active allocation (Chris) - Other execlists fixes (Chris) On Display side: - GLK HDMI fix (Clint) - Rework and cleanup around HPD pin (Ville) - Preparation work for Display Stream Compression support coming on ICL (Anusha) - Nuke LVDS lid notification (Ville) - Assume eDP is always connected (Ville) - Kill intel panel detection (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Fri 20 Jul 2018 01:51:45 AM AEST # gpg: using RSA key FA625F640EEB13CA # gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>" # gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA # Conflicts: # drivers/gpu/drm/i915/intel_lrc.c Link: https://patchwork.freedesktop.org/patch/msgid/20180719171257.GA12199@intel.com
2018-07-18Merge tag 'drm-intel-next-2018-07-09' of ↵Dave Airlie1-1/+5
git://anongit.freedesktop.org/drm/drm-intel into drm-next Higlights here goes to many PSR fixes and improvements; to the Ice lake work with power well support and begin of DSI support addition. Also there were many improvements on execlists and interrupts for minimal latency on command submission; and many fixes on selftests, mostly caught by our CI. General driver: - Clean-up on aux irq (Lucas) - Mark expected switch fall-through for dealing with static analysis tools (Gustavo) Gem: - Different fixes for GuC (Chris, Anusha, Michal) - Avoid self-relocation BIAS if no relocation (Chris) - Improve debugging cases in on EINVAL return and vma allocation (Chris) - Fixes and improvements on context destroying and freeing (Chris) - Wait for engines to idle before retiring (Chris) - Many improvements on execlists and interrupts for minimal latency on command submission (Chris) - Many fixes in selftests, specially on cases highlighted on CI (Chris) - Other fixes and improvements around GGTT (Chris) - Prevent background reaping of active objects (Chris) Display: - Parallel modeset cleanup to fix driver reset (Chris) - Get AUX power domain for DP main link (Imre) - Clean-up on PSR unused func pointers (Rodrigo) - Many PSR/PSR2 fixes and improvements (DK, Jose, Tarun) - Add a PSR1 live status (Vathsala) - Replace old drm_*_{un/reference} with put,get functions (Thomas) - FBC fixes (Maarten) - Abstract and document the usage of picking macros (Jani) - Remove unnecessary check for unsupported modifiers for NV12. (DK) - Interrupt fixes for display (Ville) - Clean up on sdvo code (Ville) - Clean up on current DSI code (Jani) - Remove support for legacy debugfs crc interface (Maarten) - Simplify get_encoder_power_domains (Imre) Icelake: - MG PLL fixes (Imre) - Add hw workaround for alpha blending (Vandita) - Add power well support (Imre) - Add Interrupt Support (Anusha) - Start to add support for DSI on Ice Lake (Madhav) Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Tue 10 Jul 2018 08:41:37 AM AEST # gpg: using RSA key FA625F640EEB13CA # gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>" # gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA Link: https://patchwork.freedesktop.org/patch/msgid/20180710234349.GA16562@intel.com
2018-07-12Merge tag 'gvt-next-2018-07-11' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi8-94/+517
drm-intel-next-queued gvt-next-2018-07-11 - vGPU huge page support (Changbin) - BXT display irq warning fix (Colin) - Handle GVT dependency well (Henry) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180711023353.GU1267@zhen-hp.sh.intel.com
2018-07-10drm/i915/gvt: declare gvt as i915's soft dependencyHang Yuan1-0/+4
This helps initramfs builder and other tools to know the full dependencies of i915 and have gvt module loaded with i915. v2: add condition and change to pre-dependency (Chris) v3: move declaration to gvt.c. (Chris) v4: remove xengt (Zhenyu) Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Handle EDP_PSR_IMR and EDP_PSR_IIR for BXT.Colin Xu1-0/+10
BXT supports EDP. However since GVT-g only simulate DP monitor to guest and handles EDP_PSR_IMR and EDP_PSR_IIR as default MMIO r/w. If guest r/w these IMR/IIR, GVT-g won't simulate the real HW behavior and below warning is printed: -------- Interrupt register 0x64838 is not zero: 0xffffffff WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:161 gen3_assert_iir_is_zero+0x34/0xa0 Call Trace: gen8_de_irq_postinstall+0xad/0x330 gen8_irq_postinstall+0x23/0x80 drm_irq_install+0xb5/0x130 i915_driver_load+0xafd/0xf70 -------- Since GVT-g won't simulate EDP to guest, always set EDP_PSR_IMR and EDP_PSR_IIR IMR/IIR to 0. Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915: Enable platform support for vGPU huge gtt pagesChangbin Du1-0/+1
Now GVTg supports shadowing both 2M/64K huge gtt pages. So let's turn on the cap info bit VGT_CAPS_HUGE_GTT. v2: Split changes in i915 side into a separated patch. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Fix error handling in ppgtt_populate_spt_by_guest_entryChangbin Du1-12/+21
Don't forget to free allocated spt if shadowing failed. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Handle special sequence on PDE IPS bitChangbin Du1-5/+15
If the guest update the 64K gtt entry before changing IPS bit of PDE, we need to re-shadow the whole page table. Because we have ignored all updates to unused entries. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add 2M huge gtt supportChangbin Du1-5/+95
This add 2M huge gtt support for GVTg. Unlike 64K gtt entry, we can shadow 2M guest entry with real huge gtt. But before that, we have to check memory physical continuous, alignment and if it is supported on the host. We can get all supported page sizes from intel_device_info.page_sizes. Finally we must split the 2M page into smaller pages if we cannot satisfy guest Huge Page. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/kvmgt: Support setting dma map for huge pagesChangbin Du4-39/+102
To support huge gtt, we need to support huge pages in kvmgt first. This patch adds a 'size' param to the intel_gvt_mpt::dma_map_guest_page API and implements it in kvmgt. v2: rebase. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add 64K huge gtt supportChangbin Du1-6/+80
Finally, this add the first huge gtt support for GVTg - 64K pages. Since 64K page and 4K page cannot be mixed on the same page table, so we always split a 64K entry into small 4K page. And when unshadow guest 64K entry, we need ensure all the shadowed entries in shadow page table also get cleared. For page table which has 64K gtt entry, only PTE#0, PTE#16, PTE#32, ... PTE#496 are used. Unused PTEs update should be ignored. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Make PTE iterator 64K entry awareChangbin Du1-2/+6
64K PTE is special, only PTE#0, PTE#16, PTE#32, ... PTE#496 are used in the page table. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Split ppgtt_alloc_spt into two partsChangbin Du1-22/+40
We need a interface to allocate a pure shadow page which doesn't have a guest page associated with. Such shadow page is used to shadow 2M huge gtt entry. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add GTT clear_pse operationChangbin Du2-0/+20
Add clear_pse operation in case we need to split huge gtt into small pages. v2: correct description. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add software PTE flag to mark special 64K splited entryChangbin Du2-0/+24
This add a software PTE flag on the Ignored bit of PTE. It will be used to identify splited 64K shadow entries. v2: fix mask definition. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Detect 64K gtt entry by IPS bit of PDEChangbin Du2-21/+51
This change help us detect the real entry type per PSE and IPS setting. For 64K entry, we also need to check reg GEN8_GAMW_ECO_DEV_RW_IA. v2: Extend IPS mmio control to Gen10. (Matthew Auld) Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Handle MMIO GEN8_GAMW_ECO_DEV_RW_IA for 64K GTTChangbin Du1-1/+28
The register RENDER_HWS_PGA_GEN7 is renamed to GEN8_GAMW_ECO_DEV_RW_IA from GEN8 which can control IPS enabling. v3: MMIO control for IPS is not removed from gen9 but gen10 (Matthew Auld) v2: IPS of all engines must be enabled together for gen9. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add PTE IPS bit operationsChangbin Du2-0/+20
Add three IPS operation functions to test/set/clear IPS in PDE. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/gvt: Add new 64K entry typeChangbin Du2-4/+23
Add a new entry type GTT_TYPE_PPGTT_PTE_64K_ENTRY. 64K entry is very different from 2M/1G entry. 64K entry is controlled by IPS bit in upper PDE. To leverage the current logic, I take IPS bit as 'PSE' for PTE level. Which means, 64K entries can also processed by get_pse_type(). v2: Make it bisectable. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-06drm/i915: Start returning an error from i915_vma_move_to_active()Chris Wilson1-1/+5
Handling such a late error in request construction is tricky, but to accommodate future patches which may allocate here, we potentially could err. To handle the error after already adjusting global state to track the new request, we must finish and submit the request. But we don't want to use the request as not everything is being tracked by it, so we opt to cancel the commands inside the request. 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/20180706103947.15919-3-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 19:04:03 +0300