- 24 Feb, 2017 2 commits
-
-
Zhenyu Wang authored
This assigns resolution definition for each vGPU type. For smaller resource type we should limit max resolution, so e.g limit to 1024x768 for 64M type, others are still default to 1920x1200. v2: Fix for actual 1920x1200 resolution Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We'll need to apply different resolution for vgpu types, so this adds more EDID types definition. v2: fix typo for actual 1920x1200 resolution Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 23 Feb, 2017 13 commits
-
-
Zhenyu Wang authored
Previous vGPU type create tried to determine vGPU type name e.g _1, _2 based on the number of mdev devices can be created, but different type might have very different resource size depending on physical device. We need to split type name vs. actual mdev resource and create fixed vGPU type with determined size for consistence. With this we'd like to fix vGPU types for _1, _2, _4 and _8 now, each type has fixed defined resource size. Available mdev instances that could be created is determined by physical resource, and user should query for that before creating. Cc: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao, Xinda authored
The guest VM may initialize the whole GTT table during boot up, so the warning msg in emulate_gtt_mmio_write is not necessary, it is the expected behavior and it may confuse the user if error msg is printed out, so remove the msg from emulate_gtt_mmio_write(), Signed-off-by: Zhao, Xinda <xinda.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Weinan Li authored
In GVT-g we always emulate as pcode read/write success and ready for access anytime, since we don't touch real physical registers here. Add 'SKL_PCODE_CDCLK_CONTROL' write emulation, without it will cause skl_set_cdclk fail in guest. Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Ping Gao authored
Releasing shadow PPGTT pages is not enough when vGPU reset, the guest page table tracking data should has same life-cycle with all the shadow PPGTT pages; Otherwise there is no chance to re-shadow the PPGTT pages without free the guest page table tracking data. This patch clear the PPGTT reset logic and make the vGPU reset in working order. v2: refactor some logic to avoid code duplicated. v3: remove useless macro and add comments from Christophe. v4: keep reset logic in reset function. Signed-off-by: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao, Xinda authored
When untracked mmio is visited, too many log info will be printed out, it may confuse the user, but most of the time, it is not the urgent case, so use gvt_dbg_mmio() instead. Signed-off-by: Zhao, Xinda <xinda.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao Yan authored
for a handled mmio reg, its default value is read from hardware, while for an unhandled mmio regs, its default value would be random if not explicitly set to 0 Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Pei Zhang authored
Linux guest is using this MMIO in lri command. Add cmd_access flag for this mmio in gvt to avoid error log. v2: change the mmio address to its macro name Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao Yan authored
add a whitelist to check the content of force-nonpriv registers v3: per He Min's comment, modify in_whitelist()'s return type to bool, and use negative value as the return value for failure for force_nonpriv_write(). v2: 1. split a big patch into two smaller ones per zhenyu's comment. this patch is the mmio handling part for force-nopriv registers 2. per zhenyu's comment, combine all non-priv registers into a single MMIO_DFH entry Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao Yan authored
the value of those registers should be applied to hardware on context restoring Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Takashi Iwai authored
send_display_send_uevent() sends two environment variable, and the first one GVT_DISPLAY_READY is set including a new line at the end of the string; that is obviously superfluous and wrong -- at least, it *looks* so when you only read the code. However, it doesn't appear in the actual output by a (supposedly unexpected) trick. The code uses snprintf() and truncates the string in size 20 bytes. This makes the string as GVT_DISPLAY_READY=0 or ...=1 including the trailing NUL-letter. That is, the '\n' found in the format string is always cut off as a result. Although the code gives the correct result, it is confusing. This patch addresses it, just removing the superfluous '\n' from the format string for avoiding further confusion. If the argument "ready" were not a bool, the size 20 should be corrected as well. But it's a bool, so we can leave the magic number 20 as is for now. FWIW, the bug was spotted by a new GCC7 warning: drivers/gpu/drm/i915/gvt/handlers.c: In function 'pvinfo_mmio_write': drivers/gpu/drm/i915/gvt/handlers.c:1042:34: error: 'snprintf' output truncated before the last format character [-Werror=format-truncation=] snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready); ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gvt/handlers.c:1042:2: note: 'snprintf' output 21 bytes into a destination of size 20 snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 04d348ae ("drm/i915/gvt: vGPU display virtualization") Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1025903Reported-by: Richard Biener <rguenther@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhao Yan authored
some registers were missing or treated as BDW only. This patch is to fix it avoid unhandled mmio wanrings v2: update commit message according to zhenyu's comment Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Chuanxiao Dong authored
Due to the request replay, context switch interrupt may come after gvt free the workload thus can cause a kernel NULL pointer kernel panic. This patch will add a simple check to avoid this for a short term. From long term, gvt workload lifecycle doesn't match with i915 request and need to find a proper way to manage this. v4: simplify the NULL pointer check. v5: add unlikely to optimize. Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Min He authored
Windows guest will notitfy GVT-g to request more resources through g2v interface, when its resources are not enough. This patch is to handle this case and let vgpu enter failsafe mode to avoid too many error messages. Signed-off-by: Min He <min.he@intel.com> Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 17 Feb, 2017 3 commits
-
-
Zhao, Xinda authored
Lots of reduntant log info will be printed out during GPU reset, including accessing untracked mmio register and fence register, variable disable_warn_untrack is added previously to handle the situation, but the accessing of fence register is ignored in the previously patch, so add it back. Besides, set the variable disable_warn_untrack to the defalut value after GPU reset is finished. Signed-off-by: Zhao, Xinda <xinda.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Min He authored
New failsafe mode is introduced, when we detect guest not supporting GVT-g. In failsafe mode, we will ignore all the MMIO and cfg space read/write from guest. This patch can fix the issue that when guest kernel or graphics driver version is too low, there will be a lot of kernel traces in host. V5: rebased onto latest gvt-staging V4: changed coding style by Zhenyu and Ping's advice V3: modified coding style and error messages according to Zhenyu's comment V2: 1) implemented MMIO/GTT/WP pages read/write logic; 2) used a unified function to enter failsafe mode Signed-off-by: Min He <min.he@intel.com> Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
As we switched to memremap for opregion, shouldn't use any __iomem for that, and move to use memcpy instead. This fixed static check errors for: CHECK drivers/gpu/drm/i915//gvt/opregion.c drivers/gpu/drm/i915//gvt/opregion.c:142:31: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915//gvt/opregion.c:142:31: expected void *addr drivers/gpu/drm/i915//gvt/opregion.c:142:31: got void [noderef] <asn:2>*opregion_va drivers/gpu/drm/i915//gvt/opregion.c:160:35: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915//gvt/opregion.c:160:35: expected void [noderef] <asn:2>*opregion_va drivers/gpu/drm/i915//gvt/opregion.c:160:35: got void * Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 14 Feb, 2017 6 commits
-
-
Chuanxiao Dong authored
When doing dma map failed for a pfn, kvmgt should unpin the pfn and return error code to device module driver Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Cc: xinda.zhao@intel.com Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Chuanxiao Dong authored
For the inhibit ctx, load all mmio in render mmio list into HW by MMIO write for ctx initialization. For the none-inhibit ctx, only load the render mmio which is not in_context into HW by MMIO write. Skip the MMIO write for in_context mmio as context image will load it. Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Xu Han authored
* Add flip done event support for sprite plane on SKL platform. * Fix bug #1452, "Call Trace:handle_default_event_virt+0xef/0x100 [i915]" while booting up guest. Signed-off-by: Xu Han <xu.han@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
We also need reset vGPU virtual display emulation. Since all vreg has been cleared, we need reset display related vreg to reflect our display setting. Signed-off-by: Changbin Du <changbin.du@intel.com> Cc: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We need to be careful to only update addr mode for gvt shadow context descriptor but keep other valid config. This fixes GPU hang caused by invalid descriptor submitted for gvt workload. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We need to properly setup alignment for GTT start/end/size as required. Fixed warning from i915 gem. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 10 Feb, 2017 1 commit
-
-
Changbin Du authored
In function dispatch_workload(), if it fail before calling intel_gvt_scan_and_shadow_wa_ctx(), the indirect ctx will not be shadowed so no cleaup need. wa_ctx->indirect_ctx.obj indicate whether indirect_ctx is shadowed. The obj is null if it is unshadowed. BUG: unable to handle kernel NULL pointer dereference at 00000000000001a0 IP: complete_execlist_workload+0x2c9/0x3e0 [i915] Oops: 0002 [#1] SMP task: ffff939546d2d880 task.stack: ffffbd9b82ac4000 RIP: 0010:complete_execlist_workload+0x2c9/0x3e0 [i915] RSP: 0018:ffffbd9b82ac7dd8 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9393c725b540 RCX: 0000000000000006 RDX: 0000000000000007 RSI: 0000000000000202 RDI: ffff939559c8dd00 RBP: ffffbd9b82ac7e18 R08: 0000000000000001 R09: 000000000120dd8f R10: 0000000000000000 R11: 000000000120dd8f R12: ffff9393c725b540 R13: ffff9393c725b618 R14: ffffbd9b81f0d000 R15: ffff939520e0e000 FS: 0000000000000000(0000) GS:ffff939559c80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000001a0 CR3: 000000043d664000 CR4: 00000000003426e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: workload_thread+0x312/0xd70 [i915] ? __wake_up_sync+0x20/0x20 ? wake_atomic_t_function+0x60/0x60 kthread+0x101/0x140 Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 09 Feb, 2017 6 commits
-
-
Chuanxiao Dong authored
gvt driver has a check which doesn't allow to use gvt when host gpu iommu is enabled. This check can be removed after enable the iommu support in gvt Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Chuanxiao Dong authored
When host i915 iommu enabled, gvt needs to use a mapped pfn in PTE entry So before kvm returns the pfn, map this pfn and return the mapped address which is so called iova. Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Chuanxiao Dong authored
MFN usually refers to "Machine Frame Number" in virtulization world. Currently GVT-g populates the shadow PPGTT/GGTT page table with MFN according to the translation between MFN and Guest PFN. When host IOMMU is enabled, GPU DMA transactions go through the IOMMU, GPU needs an IOVA<->MFN mapping to walk the shadow page table in host main memory. This patch will map a page in IOMMU page table before using it in shadow page table and release the map when a shadow page is going to be freed. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
Reduce the line of logs in below functions and log friendly. o intel_vgpu_reg_imr_handler o intel_vgpu_reg_master_irq_handler o intel_vgpu_reg_ier_handler o intel_vgpu_reg_iir_handler Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
Remove a redundant end of line in below log. 'will complete workload %p\n, status: %d\n' Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Changbin Du authored
Remove below unimportant log which is too noisy. 'no current vgpu search from q head' Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 08 Feb, 2017 1 commit
-
-
Dan Carpenter authored
"caps.buf" is always NULL here and "caps.size" is always zero. The code is a no-op and can be removed. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 07 Feb, 2017 6 commits
-
-
Zhenyu Wang authored
As now gvt init after knowing hw resource info, we can determine vGPU type from machine size instead of pre-defined value. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
As now gvt init is late after MMIO initialization, use normal MMIO read function for initial firmware exposure if no available firmware loaded. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
We only depend on pvinfo register for GVT-g state detection, not require hypervisor host detect any more. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
Prepare to remove detect_host() hook. Move intel iommu detection early in intel_gvt_init(). Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Zhenyu Wang authored
Previously intel_gvt_init() was called very early even before MMIO initialization which had several drawbacks: - Have to handle MMIO access for initial MMIO state dump if golden state firmware is not available - Hypervisor detection should depend on pvinfo only instead of detecting hypervisor status. - Don't know hw resource size e.g aperture, ggtt size to determine for vGPU type, etc. This trys to move intel_gvt_init() call late after required info has already been initialized for GVT host. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
Chuanxiao Dong authored
The current virtual edid can only support the resolution up to 1024x768. Update the virtual edid so that can support more resoltions. With this new virtual edid, resolution can be up to 1920x1200. V2: add detailed modeline description in edid code comments Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 31 Jan, 2017 2 commits
-
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next adding runtime PM support to MIC driver, and including some cleanups - especially using atomic helper functions instead of specific ones - and fixups. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: g2d: prevent integer overflow in drm/exynos: fix a timeout loop drm/exynos: use atomic helper commit drm/exynos: remove unnecessary codes drm/exynos: mic: Add runtime PM support drm/exynos: Stop using drm_framebuffer_unregister_private drm/exynos: mic: Fix parse_dt function drm/exynos: mic: Add mode_set callback function
-
Dave Airlie authored
Merge tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-next Allwinner DRM changes for 4.11 Just one minor fix. * tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: drm/sun4i: Fix a return value in case of error
-