summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/gvt/mpt.h
AgeCommit message (Collapse)AuthorFilesLines
2020-11-23drm/i915/gvt: treat intel_gvt_mpt as const in gvt codeJulian Stecklina1-1/+1
The current interface of intel_gvt_register_hypervisor() expects a non-const pointer to struct intel_gvt_mpt, even though the mediator never modifies (or should modifiy) the content of this struct. Change the function signature and relevant struct members to const to properly express the API's intent and allow instances of intel_gvt_mpt to be allocated as const. While I was here, I also made KVM's instance of this struct const to reduce the number of writable function pointers in the kernel. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201111172811.558443-1-julian.stecklina@cyberus-technology.de
2019-12-13drm/i915/gvt: Pin vgpu dma address before usingTina Zhang1-0/+15
Dma-buf display uses the vgpu dma address saved in the guest part GGTT table which is updated by vCPU thread. In host side, when the dma address is used by qemu ui thread, gvt-g must make sure the dma address is validated before letting it go to the HW. Invalid guest dma address will easily cause DMA fault and make GPU hang. v2: Rebase Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Acked-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> Link: http://patchwork.freedesktop.org/patch/msgid/20191212141342.3417-1-tina.zhang@intel.com
2019-02-18Merge v5.0-rc7 into drm-nextDave Airlie1-1/+1
Backmerging for nouveau and imx that needed some fixes for next pulls. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-01-31drm/i915/gvt: add VFIO EDID regionHang Yuan1-0/+17
Implement VFIO EDID region for vgpu. Support EDID blob update and notify guest on link state change via hotplug event. v3: move struct edid_region to kvmgt.c <zhenyu> v2: add EDID sanity check and size update <zhenyu> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-01-15drm/i915/gvt: free VFIO region space in vgpu detachHang Yuan1-1/+1
VFIO region space is allocated when one region is registered for one vgpu. So free the space when destroy the vgpu. Also change the parameter of detach_vgpu callback to use vgpu directly. Fixes: b851adeac0858c7d257b3 ("drm/i915/gvt: Add opregion support") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-01-02drm/i915/gvt: Change KVMGT as self load moduleZhenyu Wang1-0/+3
This trys to make 'kvmgt' module as self loadable instead of loading by i915/gvt device model. So hypervisor specific module could be stand-alone, e.g only after loading hypervisor specific module, GVT feature could be enabled via specific hypervisor interface, e.g VFIO/mdev. So this trys to use hypervisor module register/unregister interface for that. Hypervisor module needs to take care of module reference itself when working for hypervisor interface, e.g for VFIO/mdev, hypervisor module would reference counting mdev when open and release. This makes 'kvmgt' module really split from GVT device model. User needs to load 'kvmgt' to enable VFIO/mdev interface. v6: - remove unused variable v5: - put module reference in register error path v4: - fix checkpatch warning v3: - Fix module reference handling for device open and release. Unused mdev devices would be cleaned up in device unregister when module unload. v2: - Fix kvmgt order after i915 for built-in case Cc: "Yuan, Hang" <hang.yuan@intel.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: "He, Min" <min.he@intel.com> Reviewed-by: Yuan, Hang <hang.yuan@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-12-10drm/i915/gvt: remove unused parameter for hypervisor's host_exit callZhenyu Wang1-3/+2
The parameter 'void *gvt' is not used and required for hypervisor's exit call. Even for non-merged Xen hypervisor support. So just remove it. Reviewed-by: Yuan, Hang <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-12-10drm/i915/gvt: mandatory require hypervisor's host_initZhenyu Wang1-3/+2
Don't mark hypervisor module's host_init as optional, but mandatory required. Reviewed-by: Yuan, Hang <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-07-09drm/i915/kvmgt: Support setting dma map for huge pagesChangbin Du1-3/+4
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-03-06drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup overheadChangbin Du1-0/+28
The implementation of current kvmgt implicitly setup dma mapping at MPT API gfn_to_mfn. First this design against the API's original purpose. Second, there is no unmap hit in this design. The result is that the dma mapping keep growing larger and larger. For mutl-vm case, they will consume IOMMU IOVA low 4GB address space quickly and so tons of rbtree entries crated in the IOMMU IOVA allocator. Finally, single IOVA allocation can take as long as ~70ms. Such latency is intolerable. To address both above issues, this patch introduced two new MPT API: o dma_map_guest_page - setup dma map for guest page o dma_unmap_guest_page - cancel dma map for guest page The kvmgt implements these 2 API. And to reduce dma setup overhead for duplicated pages (eg. scratch pages), two caches are used: one is for mapping gfn to struct gvt_dma, another is for mapping dma addr to struct gvt_dma. With these 2 new API, the gtt now is able to cancel dma mapping when page table is invalidated. The dma mapping is not in a gradual increase now. v2: follow the old logic for VFIO_IOMMU_NOTIFY_DMA_UNMAP at this point. Cc: Hang Yuan <hang.yuan@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-03-06drm/i915/gvt: Don't extend page_track to mpt layerChangbin Du1-28/+6
Don't extend page_track to mpt layer. Keep MPT simple and clean. Meanwhile remove gtt.n_tracked_guest_page which doesn't make much sense. v2: clean up gtt.n_tracked_guest_page. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-03-06drm/i915/gvt: Rename mpt api {set, unset}_wp_page to {enable, ↵Changbin Du1-5/+4
disable}_page_track The kvmgt's implementation of mpt api {set,unset}_wp_page is not real write-protection - the data get written before invoke this two api. As discussed, change the mpt api to match the real behavior. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-02-01drm/i915/gvt: validate gfn before set shadow page entryHang Yuan1-0/+17
GVT may receive partial write on one guest PTE update. Validate gfn not to translate incomplete gfn. This avoids some unnecessary error messages incurred by the incomplete gfn translating. Also fix the bug that the whole PPGTT shadow page update is aborted on any invalid gfn entry. gfn validation relys on hypervisor's help. Add one MPT module function to provide the function. Signed-off-by: Hang Yuan <hang.yuan@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2017-12-04drm/i915/gvt: Dmabuf support for GVT-gTina Zhang1-0/+30
This patch introduces a guest's framebuffer sharing mechanism based on dma-buf subsystem. With this sharing mechanism, guest's framebuffer can be shared between guest VM and host. v17: - modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex) v16: - add x_hot and y_hot. (Gerd) - add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex) - rebase 4.14.0-rc6. v15: - add VFIO_DEVICE_GET_GFX_DMABUF ABI. (Gerd) - add intel_vgpu_dmabuf_cleanup() to clean up the vGPU's dmabuf. (Gerd) v14: - add PROBE, DMABUF and REGION flags. (Alex) v12: - refine the lifecycle of dmabuf. v9: - remove dma-buf management. (Alex) - track the dma-buf create and release in kernel mode. (Gerd) (Daniel) v8: - refine the dma-buf ioctl definition.(Alex) - add a lock to protect the dmabuf list. (Alex) v7: - release dma-buf related allocations in dma-buf's associated release function. (Alex) - refine ioctl interface for querying plane info or create dma-buf. (Alex) v6: - align the dma-buf life cycle with the vfio device. (Alex) - add the dma-buf related operations in a separate patch. (Gerd) - i915 related changes. (Chris) v5: - fix bug while checking whether the gem obj is gvt's dma-buf when user change caching mode or domains. Add a helper function to do it. (Xiaoguang) - add definition for the query plane and create dma-buf. (Xiaoguang) v4: - fix bug while checking whether the gem obj is gvt's dma-buf when set caching mode or doamins. (Xiaoguang) v3: - declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode and domains can not be changed for this kind of gem object. (Alex) - change dma-buf related information to be more generic. So other vendor can use the same interface. (Alex) v2: - create a management fd for dma-buf operations. (Alex) - alloc gem object's backing storage in gem obj's get_pages() callback. (Chris) Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-12-04drm/i915/gvt: Add opregion supportTina Zhang1-0/+15
Windows guest driver needs vbt in opregion, to configure the setting for display. Without opregion support, the display registers won't be set and this blocks display model to get the correct information of the guest display plane. This patch is to provide a virtual opregion for guest. The original author of this patch is Xiaoguang Chen. This patch is split from the "Dma-buf support for GVT-g" patch set, with being rebased to the latest gvt-staging branch. v3: - add checking region index during intel_vgpu_rw. (Xiong) v2: - refine intel_vgpu_reg_release_opregion. (Xiong) Here are the previous version comments: v18: - unmap vgpu's opregion when destroying vgpu. v16: - rebase to 4.14.0-rc6. Signed-off-by: Bing Niu <bing.niu@intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Tested-by: Xiong Zhang <xiong.y.zhang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-11-16drm/i915/gvt: Factor intel_vgpu_page_trackZhi Wang1-16/+18
As the data structure of "intel_vgpu_guest_page" will become much heavier in future, it's better to factor out the guest memory page track mechnisim as early as possible. Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
2017-06-08drm/i915/gvt: Change flood gvt dmesg into traceXiong Zhang1-2/+1
Currently gvt dmesg is so heavy at drm.debug=0x2 that guest and host almost couldn't run on xengt. This patch transfer these repeated messages into trace, so dmesg is light at drm.debug=0x2, and user could get the target message through trace event and trace filter. Suggested-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-02-07drm/i915/gvt: remove detect_host() MPT hookZhenyu Wang1-12/+0
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>
2016-11-10drm/i915/gvt: allow several MPT methods to be NULLJike Song1-0/+24
Hypervisors are different, the MPT ops is a only superset of all possibly supported hypervisors. There might be other way out of the MPT to achieve same target. e.g. vfio-based kvmgt won't provide map_gfn_to_mfn method to establish guest EPT mapping for aperture, since it will be done in QEMU/KVM, MMIO is also trapped elsewhere, etc. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-11-10drm/i915/gvt: introduce host_init/host_exit to MPTJike Song1-0/+21
GVT host needs init/exit hooks to do some initialization/cleanup work, e.g.: vfio mdev host device register/unregister. Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-11-10drm/i915/gvt: remove obsolete code for old kvmgt opregionJike Song1-8/+2
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>
2016-10-14drm/i915/gvt: vGPU PCI configuration space virtualizationZhi Wang1-0/+42
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>
2016-10-14drm/i915/gvt: vGPU graphics memory virtualizationZhi Wang1-0/+107
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>
2016-10-14drm/i915/gvt: vGPU interrupt virtualization.Zhi Wang1-0/+38
This patch introduces vGPU interrupt emulation framework. The vGPU intrerrupt emulation framework is an event-based interrupt emulation framework. It's responsible for emulating GEN hardware interrupts during emulating other HW behaviour. It consists several components: - Descriptions of interrupt register bit - Upper level <-> lower level interrupt mapping - GEN HW IER/IMR/IIR register emulation routines - Event-based interrupt propagation interface When a GVT-g component wants to inject an interrupt to a VM during a emulation, first it should specify the event needs to be emulated and the framework will deal with the rest of emulation: - Generating related virtual IIR bit according to virtual IER and IMRs, - Generate related virtual upper level virtual IIR bit accodring to the per-platform interrupt mapping - Injecting a MSI to VM Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-14drm/i915/gvt: Introduce basic vGPU life cycle managementZhi Wang1-0/+33
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>
2016-06-17drm/i915: gvt: Introduce the basic architecture of GVT-gZhi Wang1-0/+49
This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v12: - Call intel_gvt_init() in driver early initialization stage. (Chris) v8: - Remove the GVT idr and mutex in intel_gvt_host. (Joonas) v7: - Refine the URL link in Kconfig. (Joonas) - Refine the introduction of GVT-g host support in Kconfig. (Joonas) - Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas) - Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas) - Remove {alloc, free}_gvt_device() - Rename intel_gvt_{create, destroy}_gvt_device() - Expost intel_gvt_init_host() - Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas) v6: - Refine introduction in Kconfig. (Chris) - The exposed API functions will take struct intel_gvt * instead of void *. (Chris/Tvrtko) - Remove most memebers of strct intel_gvt_device_info. Will add them in the device model patches.(Chris) - Remove gvt_info() and gvt_err() in debug.h. (Chris) - Move GVT kernel parameter into i915_params. (Chris) - Remove include/drm/i915_gvt.h, as GVT-g will be built within i915. - Remove the redundant struct i915_gvt *, as the functions in i915 will directly take struct intel_gvt *. - Add more comments for reviewer. v5: Take Tvrtko's comments: - Fix the misspelled words in Kconfig - Let functions take drm_i915_private * instead of struct drm_device * - Remove redundant prints/local varible initialization v3: Take Joonas' comments: - Change file name i915_gvt.* to intel_gvt.* - Move GVT kernel parameter into intel_gvt.c - Remove redundant debug macros - Change error handling style - Add introductions for some stub functions - Introduce drm/i915_gvt.h. Take Kevin's comments: - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c v2: - Introduce i915_gvt.c. It's necessary to introduce the stubs between i915 driver and GVT-g host, as GVT-g components is configurable in kernel config. When disabled, the stubs here do nothing. Take Joonas' comments: - Replace boolean return value with int. - Replace customized info/warn/debug macros with DRM macros. - Document all non-static functions like i915. - Remove empty and unused functions. - Replace magic number with marcos. - Set GVT-g in kernel config to "n" by default. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-5-git-send-email-zhi.a.wang@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>