summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/gvt/vgpu.c
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915/gvt: move cfg space inititation function to cfg_space.cChangbin Du2017-01-131-43/+1
| | | | | | | | | Move the configuration space inititation function setup_vgpu_cfg_space() in vgpu.c to dedicated source file cfg_space.c, and rename the function as intel_vgpu_init_cfg_space(). Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: destroy the allocated idr on vgpu creating failuresJike Song2017-01-091-1/+3
| | | | | | | | | Once idr_alloc gets called data is allocated within the idr list, if any error occurs afterwards, we should undo that by idr_remove on the error path. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: adjust high memory size for default vGPU typeZhenyu Wang2017-01-091-2/+2
| | | | | | | | Previous high mem size initialized for vGPU type was too small which caused failure for some VMs. This trys to take minimal value of 384MB for each VM and enlarge default high mem size to make guest driver happy. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: fix missing init param.primaryDu, Changbin2016-11-231-0/+1
| | | | | | | Initiate param.primary to 1. We should be primary currently. Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: clear guest opregionXiaoguang Chen2016-11-141-0/+1
| | | | | | | | Since there's no opregion in vgpu so clear the opregion bits in case guest access it. Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: fix mem leakage in setup_vgpu_mmio for vgpu resetDu, Changbin2016-11-141-3/+7
| | | | | | | | | | Gvt gdrst handler handle_device_reset() invoke function setup_vgpu_mmio() to reset mmio status. In this case, the virtual mmio memory has been allocated already. The new allocation just cause old mmio memory leakage. Signed-off-by: Du, Changbin <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: refactor intel_gvt_io_emulation_ops to be intel_gvt_opsJike Song2016-11-101-0/+11
| | | | | | | | | | | | There are currently 4 methods in intel_gvt_io_emulation_ops to emulate CFG/MMIO reading/writing for intel vGPU. A possibly better scope is: add 3 more methods for vgpu create/destroy/reset respectively, and rename the ops to 'intel_gvt_ops', then pass it to the MPT module (say the future kvmgt) to use: they are all methods for external usage. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: remove obsolete code for old kvmgt opregionJike Song2016-11-101-9/+1
| | | | | | | | | | Current GVT contains some obsolete logic originally cooked to support the old, non-vfio kvmgt, which is actually workarounds. We don't support that anymore, so it's safe to remove it and make a better framework. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: add intel vgpu types supportZhenyu Wang2016-11-101-11/+137
| | | | | | | | By providing predefined vGPU types, users can choose which type a vgpu to create and use, without specifying detailed parameters. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jike Song <jike.song@intel.com>
* drm/i915/gvt: add full vGPU reset supportPing Gao2016-10-271-2/+2
| | | | | | | | | Full vGPU reset need to release all the shadow PPGGT pages to avoid unnecessary write-protect and also should re-initialize pvinfo after resetting vregs to keep pvinfo correct. Signed-off-by: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: clean up intel_gvt.h as interface for i915 coreZhenyu Wang2016-10-201-0/+2
| | | | | | | | | | | | | | | | | | | | | i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. v2: Fix per Chris's comment - carefully handle dev_priv->gvt assignment - add necessary bracket for macro helper - forward declartion struct intel_gvt - keep free operation within same file handling alloc v3: fix use after free and remove intel_gvt.initialized v4: change to_gvt() to an inline Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU context switchZhi Wang2016-10-141-0/+1
| | | | | | | | | As different VM may configure different render MMIOs when executing workload, to schedule workloads between different VM, the render MMIOs have to be switched. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU schedule policy frameworkZhi Wang2016-10-141-0/+14
| | | | | | | | This patch introduces a vGPU schedule policy framework, with a timer based schedule policy module for now Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU workload schedulerZhi Wang2016-10-141-0/+7
| | | | | | | | | | | | | | This patch introduces the vGPU workload scheduler routines. GVT workload scheduler is responsible for picking and executing GVT workload from current scheduled vGPU. Before the workload is submitted to host i915, the guest execlist context will be shadowed in the host GVT shadow context. the instructions in guest ring buffer will be copied into GVT shadow ring buffer. Then GVT-g workload scheduler will scan the instructions in guest ring buffer and submit it to host i915. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU workload submissionZhi Wang2016-10-141-0/+1
| | | | | | | | | | | | This patch introduces the vGPU workload submission logics. Under virtualization environment, guest will submit workload through virtual execlist submit port. The submitted workload load will be wrapped into an gvt workload which will be picked by GVT workload scheduler and executed on host i915 later. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU execlist virtualizationZhi Wang2016-10-141-0/+6
| | | | | | | | | | | This patch introduces the vGPU execlist virtualization. Under virtulization environment, HW execlist interface are fully emulated including virtual CSB emulation, virtual execlist emulation. The framework will emulate the virtual CSB according to the guest workload running status Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU display virtualizationZhi Wang2016-10-141-0/+7
| | | | | | | | | | | | | This patch introduces the GVT-g display virtualization. It consists a collection of display MMIO handlers, like power well register handler, pipe register handler, plane register handler, which will emulate all display MMIOs behavior to support virtual mode setting sequence for guest. Signed-off-by: Bing Niu <bing.niu@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU MMIO virtualizationZhi Wang2016-10-141-0/+5
| | | | | | | | | | This patch introduces the generic vGPU MMIO emulation intercept framework. The MPT modules will request GVT-g core logic to emulate MMIO read/write through IO emulation operations callback when hypervisor trapped a guest GTTMMIO read/write. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU PCI configuration space virtualizationZhi Wang2016-10-141-0/+9
| | | | | | | | | | | | | | | This patch introduces vGPU PCI configuration space virtualization. - Adjust the trapped GPFN(Guest Page Frame Number) window of virtual GEN PCI BAR 0 when guest initializes PCI BAR 0 address. - Emulate OpRegion when guest touches OpRegion. - Pass-through a part of aperture to guest when guest initializes aperture BAR. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: vGPU graphics memory virtualizationZhi Wang2016-10-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vGPU graphics memory emulation framework is responsible for graphics memory table virtualization. Under virtualization environment, a VM will populate the page table entry with guest page frame number(GPFN/GFN), while HW needs a page table filled with MFN(Machine frame number). The relationship between GFN and MFN(Machine frame number) is managed by hypervisor, while GEN HW doesn't have such knowledge to translate a GFN. To solve this gap, shadow GGTT/PPGTT page table is introdcued. For GGTT, the GFN inside the guest GGTT page table entry will be translated into MFN and written into physical GTT MMIO registers when guest write virtual GTT MMIO registers. For PPGTT, a shadow PPGTT page table will be created and write-protected translated from guest PPGTT page table. And the shadow page table root pointers will be written into the shadow context after a guest workload is shadowed. vGPU graphics memory emulation framework consists: - Per-GEN HW platform page table entry bits extract/de-extract routines. - GTT MMIO register emulation handlers, which will call hypercall to do GFN->MFN translation when guest write GTT MMIO register - PPGTT shadow page table routines, e.g. shadow create/destroy/out-of-sync Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* drm/i915/gvt: Introduce basic vGPU life cycle managementZhi Wang2016-10-141-0/+215
A vGPU represents a virtual Intel GEN hardware, which consists following virtual resources: - Configuration space (virtualized) - HW registers (virtualized) - GGTT memory space (partitioned) - GPU page table (shadowed) - Fence registers (partitioned) * virtualized: fully emulated by GVT-g. * partitioned: Only a part of the HW resource is allowed to be accessed by VM. * shadowed: Resource needs to be translated and shadowed before getting applied into HW. This patch introduces vGPU life cycle management framework, which is responsible for creating/destroying a vGPU and preparing/free resources related to a vGPU. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
OpenPOWER on IntegriCloud