- 06 11月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
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: NSergii Romantsov <sergii.romantsov@globallogic.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108282Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181025091823.20571-2-chris@chris-wilson.co.uk (cherry picked from commit 6fc4e48f) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 31 10月, 2018 3 次提交
-
-
由 Longhe Zheng 提交于
GVT-g only simulates DP port for guest and leaves EDP_PSR_IMR and EDP_PSR_IIR registers as default MMIO read/write. So guest won't get expected initial values of these registers when initializing the gpu driver, which results in following warning and logs. -------- Interrupt register 0x64838 is not zero: 0xffffffff WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/i915/i915_irq.c:177 gen3_assert_iir_is_zero+0x38/0xa0 Call Trace: gen8_de_irq_postinstall+0xa7/0x400 gen8_irq_postinstall+0x27/0x80 drm_irq_install+0xbc/0x140 i915_driver_load+0xa9d/0xd50 -------- Because GVT-g does not handle EDP(embedded DP) simulation for guests, always set EDP_PSR_IMR and EDP_PSR_IIR to value 0. Signed-off-by: NLonghe Zheng <longhe.zheng@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Xinyun Liu 提交于
CSFE_CHICKEN1(0x20d4) needs access with mask. This is caught in AcrnGT conformance check test: [drm:intel_gvt_vgpu_conformance_check] *ERROR* gvt: vgpu1 unconformance mmio 0x20d4:0x40004,0x4 Signed-off-by: NXinyun Liu <xinyun.liu@intel.com> Signed-off-by: NZhi Wang <zhi.a.wang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Hang Yuan 提交于
Previously we assumed two 4-byte writes to the same PTE coming in sequence. But recently we observed inconsecutive partial write happening as well. So this patch enhances the previous solution. It now uses a list to save more partial writes. If one partial write can be combined with another one in the list to construct a full PTE, update its shadow entry. Otherwise, save the partial write in the list. v2: invalidate old entry and flush ggtt (Zhenyu) v3: split old ggtt page unmap to another patch (Zhenyu) v4: refine codes (Zhenyu) Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Xiaolin Zhang <xiaolin.zhang@intel.com> Cc: Zhenyu Wang <zhenyu.z.wang@intel.com> Reviewed-by: NXiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 08 10月, 2018 1 次提交
-
-
由 Hang Yuan 提交于
Previously only cancelled dma map of a ggtt page when the ggtt entry was cleared. This patch will cancel dma map of an old ggtt page as well when the ggtt entry is updated with new page address. Fixes: 7598e870(drm/i915/gvt: Missed to cancel dma map for ggtt entries) Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 18 9月, 2018 4 次提交
-
-
由 Zhipeng Gong 提交于
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: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: NZhipeng Gong <zhipeng.gong@intel.com> Reviewed-by: NHang Yuan <hang.yuan@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Weinan Li 提交于
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: cc753fbe ("drm/i915/gvt: validate gfn before set shadow page") Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NWeinan Li <weinan.z.li@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Colin Xu 提交于
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: NHe, Min <min.he@intel.com> Signed-off-by: NColin Xu <colin.xu@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Colin Xu 提交于
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: c8ab5ac3 ("drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY") Reviewed-by: NHe, Min <min.he@intel.com> Signed-off-by: NColin Xu <colin.xu@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 06 9月, 2018 1 次提交
-
-
由 Weinan Li 提交于
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: 4023f301 ("drm/i915/gvt: opregion virtualization for win") CC: Xiaolin Zhang <xiaolin.zhang@intel.com> Reviewed-by: NXiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: NWeinan Li <weinan.z.li@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 04 9月, 2018 1 次提交
-
-
由 Zhenyu Wang 提交于
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: NZhi Wang <zhi.a.wang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 03 9月, 2018 1 次提交
-
-
由 Zhenyu Wang 提交于
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 2621cefa("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: NHang Yuan <hang.yuan@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 30 8月, 2018 5 次提交
-
-
由 Zhenyu Wang 提交于
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: e546e281 ("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: NColin Xu <Colin.Xu@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Hang Yuan 提交于
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: b24881e0("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio Cc: <stable@vger.kernel.org> Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Colin Xu 提交于
Recent patch introduce strict check on scanning cmd: Commit 8d458ea0 ("drm/i915/gvt: return error on cmd access") Before 8d458ea0, 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: NColin Xu <colin.xu@intel.com> Acked-by: NZhao Yan <yan.y.zhao@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Colin Xu 提交于
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: NColin Xu <colin.xu@intel.com> Reviewed-by: NHe, Min <min.he@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Xiaolin Zhang 提交于
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: NXiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 17 8月, 2018 2 次提交
-
-
由 Lucas De Marchi 提交于
The definition on i915_reg.h is going to change to depend on dev_priv->gpio_mmio_base being properly initialized. Define our own macros since init_generic_mmio_info() is called before than gpio_mmio_base being set. Cc: intel-gvt-dev@lists.freedesktop.org Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-2-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
This is the only place that they are being used - the others use the GMBUS* macros that rely on dev_priv being already properly initialized. Cc: intel-gvt-dev@lists.freedesktop.org Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-1-lucas.demarchi@intel.com
-
- 14 8月, 2018 6 次提交
-
-
由 Yi Wang 提交于
The 'sparse' variable may leak when return in function intel_vgpu_ioctl(), and this patch fix this. Signed-off-by: NYi Wang <wang.yi59@zte.com.cn> Reviewed-by: NJiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Dan Carpenter 提交于
The > should be >= here so that we don't read one element beyond the end of the array. Fixes: 28a60dee ("drm/i915/gvt: vGPU HW resource management") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Gustavo A. R. Silva 提交于
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: NGustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhao Yan 提交于
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: NZhao Yan <yan.y.zhao@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Hang Yuan 提交于
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: e546e281("drm/i915/gvt: Dmabuf support for GVT-g") Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Hang Yuan 提交于
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: bc7b0be3("drm/i915/gvt: Add basic debugfs infrastructure") Fixes: afe04fbe("drm/i915/gvt: create an idle vGPU") Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 13 8月, 2018 1 次提交
-
-
由 Hang Yuan 提交于
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: NHang Yuan <hang.yuan@linux.intel.com> Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 08 8月, 2018 1 次提交
-
-
由 Imre Deak 提交于
Similarly to the previous patch use a separate request/status HW flag index defined right after the corresponding control registers instead of depending for this on the power well IDs. Since the set of control/status registers varies among the different power wells (on a single platform), also add a new i915_power_well_registers struct that we populate and assign to each DDI power well as needed. Also clarify a bit the code comment describing the function and layout of the control registers. This also fixes a problem on ICL, where we incorrectly read the KVMR control register in hsw_power_well_requesters() even for DDI and AUX power wells. v2: - Clarify platform range tags in code comments. (Paulo) - Fix line over 80 chars checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
-
- 07 8月, 2018 5 次提交
-
-
由 Dan Carpenter 提交于
The dma_mapping_error() returns true on error but we want to return -ENOMEM here. Fixes: 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
To consolidate all gvt private MMIO definition in one place, this moves some not yet used in i915 to reg.h. Reviewed-by: NHang Yuan <hang.yuan@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
Caught by W=1 to fix left wrong function comment doc. Reviewed-by: NHang Yuan <hang.yuan@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhenyu Wang 提交于
Make kvmgt_dma_map/unmap_guest_page as static function. Reviewed-by: NHang Yuan <hang.yuan@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Michał Winiarski 提交于
gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality: commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages") And yet, part of it was reintroduced in: commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages") Causing kvmgt part to no longer build. Let's remove it. Reported-by: NTomasz Lis <tomasz.lis@intel.com> Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com (cherry picked from commit 4eaf317a) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 02 8月, 2018 2 次提交
-
-
由 Zhao Yan 提交于
if a context is a restore inhibit context, gfx hw only load the first page for ring context, so we only need to copy from guest the 1 page too. v3: use "return" instead of "goto" for inhibit case. (zhenyu wang) v2: move judgement of restore inhibit to a macro in mmio_context.h Signed-off-by: NZhao Yan <yan.y.zhao@intel.com> Acked-by: NHang Yuan <hang.yuan@linux.intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Zhao Yan 提交于
MI_NOOP is a common command appearing in almost all command buffers, put it into a fastpath can improve perfomance, especially in command buffers contains lots of MI_NOOPs (0s). Take glmark2 as an example, 3% performance increase is observed after introduced this patch. Meanwhile, in case where abundant in MI_NOOPs, up to 12% performance increase is measured. v2: use lowercase for index of MI_NOOP in cmd_info (zhenyu wang) Signed-off-by: NLi Weinan <weinan.z.li@intel.com> Signed-off-by: NZhao Yan <yan.y.zhao@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 24 7月, 2018 1 次提交
-
-
由 Michał Winiarski 提交于
gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality: commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages") And yet, part of it was reintroduced in: commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages") Causing kvmgt part to no longer build. Let's remove it. Reported-by: NTomasz Lis <tomasz.lis@intel.com> Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com
-
- 10 7月, 2018 1 次提交
-
-
由 Hang Yuan 提交于
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: NHang Yuan <hang.yuan@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 09 7月, 2018 4 次提交
-
-
由 Colin Xu 提交于
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: NColin Xu <colin.xu@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Changbin Du 提交于
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: NChangbin Du <changbin.du@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Changbin Du 提交于
Don't forget to free allocated spt if shadowing failed. Signed-off-by: NChangbin Du <changbin.du@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
由 Changbin Du 提交于
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: NChangbin Du <changbin.du@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-