summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gvt/gvt.h
AgeCommit message (Collapse)Author
2021-05-17drm/i915/gvt: Move mdev attribute groups into kvmgt moduleZhenyu Wang
As kvmgt module contains all handling for VFIO/mdev, leaving mdev attribute groups in gvt module caused dependency issue. Although it was there for possible other hypervisor usage, that turns out never to be true. So this moves all mdev handling into kvmgt module completely to resolve dependency issue. With this fix, no config workaround is required. So revert previous workaround commits: adaeb718d46f ("vfio/gvt: fix DRM_I915_GVT dependency on VFIO_MDEV") and 07e543f4f9d1 ("vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV"). Reviewed-by: Colin Xu <colin.xu@intel.com> Cc: Arnd Bergmann <arnd@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210513083902.2822350-1-zhenyuw@linux.intel.com
2021-04-28Merge tag 'vfio-v5.13-rc1' of git://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO updates from Alex Williamson: - Embed struct vfio_device into vfio driver structures (Jason Gunthorpe) - Make vfio_mdev type safe (Jason Gunthorpe) - Remove vfio-pci NVLink2 extensions for POWER9 (Christoph Hellwig) - Update vfio-pci IGD extensions for OpRegion 2.1+ (Fred Gao) - Various spelling/blank line fixes (Zhen Lei, Zhou Wang, Bhaskar Chowdhury) - Simplify unpin_pages error handling (Shenming Lu) - Fix i915 mdev Kconfig dependency (Arnd Bergmann) - Remove unused structure member (Keqian Zhu) * tag 'vfio-v5.13-rc1' of git://github.com/awilliam/linux-vfio: (43 commits) vfio/gvt: fix DRM_I915_GVT dependency on VFIO_MDEV vfio/iommu_type1: Remove unused pinned_page_dirty_scope in vfio_iommu vfio/mdev: Correct the function signatures for the mdev_type_attributes vfio/mdev: Remove kobj from mdev_parent_ops->create() vfio/gvt: Use mdev_get_type_group_id() vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV vfio/mbochs: Use mdev_get_type_group_id() vfio/mdpy: Use mdev_get_type_group_id() vfio/mtty: Use mdev_get_type_group_id() vfio/mdev: Add mdev/mtype_get_type_group_id() vfio/mdev: Remove duplicate storage of parent in mdev_device vfio/mdev: Add missing error handling to dev_set_name() vfio/mdev: Reorganize mdev_device_create() vfio/mdev: Add missing reference counting to mdev_type vfio/mdev: Expose mdev_get/put_parent to mdev_private.h vfio/mdev: Use struct mdev_type in struct mdev_device vfio/mdev: Simplify driver registration vfio/mdev: Add missing typesafety around mdev_device vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's ...
2021-04-12vfio/gvt: Use mdev_get_type_group_id()Jason Gunthorpe
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the supported_type_groups array, so the type_group_id is also the index into gvt->types. Use it directly and remove the string matching. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Message-Id: <16-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-03-16Merge tag 'gvt-next-2021-03-16' of https://github.com/intel/gvt-linux into ↵Jani Nikula
drm-intel-next gvt-next-2021-03-16 - Parse accurate vGPU virtual display rate (Colin) - Convert vblank timer as per-vGPU based on current rate (Colin) - spelling fix (Bhaskar) Signed-off-by: Jani Nikula <jani.nikula@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210316074330.GC1551@zhen-hp.sh.intel.com
2021-03-01drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual displayColin Xu
Current vblank emulator uses single hrtimer at 16ms period for all vGPUs, which introduces three major issues: - 16ms matches the refresh rate at 62.5Hz (instead of 60Hz) which doesn't follow standard timing. This leads to some frame drop or glitch issue during video playback. SW expects a vsync interval of 16.667ms or higher precision for an accurate 60Hz refresh rate. However current vblank emulator only works at 16ms. - Doesn't respect the fact that with current virtual EDID timing set, not all resolutions are running at 60Hz. For example, current virtual EDID also supports refresh rate at 56Hz, 59.97Hz, 60Hz, 75Hz, etc. - Current vblank emulator use single hrtimer for all vGPUs. Regardsless the possibility that different guests could run in different resolutions, all vsync interrupts are injected at 16ms interval with same hrtimer. Based on previous patch which decode guest expected refresh rate from vreg, the vblank emulator refactor patch makes following changes: - Change the vblank emulator hrtimer from gvt global to per-vGPU. By doing this, each vGPU display can operates at different refresh rates. Currently only one dislay is supported for each vGPU so per-vGPU hrtimer is enough. If multiple displays are supported per-vGPU in future, we can expand to per-PIPE further. - Change the fixed hrtimer period from 16ms to dynamic based on vreg. GVT is expected to emulate the HW as close as possible. So reflacting the accurate vsync interrupt interval is more correct than fixed 16ms. - Change the vblank timer period and start the timer on PIPECONF change. The initial period is updated to 16666667 based on 60Hz refresh rate. According to PRM, PIPECONF controls the timing generator of the connected display on this pipe, so it's safe to stop hrtimer on PIPECONF disabling, and re-start hrtimer at new period on enabling. Other changes including: - Move vblank_timer_fn from irq.c into display.c. - Clean per-vGPU vblank timer at clean_display instead of clean_irq. To run quick test, launch a web browser and goto URL: www.displayhz.com The actual refresh rate from guest can now always match guest settings. V2: Rebase to 5.11. Remove unused intel_gvt_clean_irq(). Simplify enable logic in update_vblank_emulation(). (zhenyu) Loop all vGPU by idr when check all vblank timer. (zhenyu) Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-03-01drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vregColin Xu
Guest OS builds up its timing mode list based on the virtual EDID as simulated by GVT. However since there are several timings supported in the virtual EDID, and each timing can also support several modes (resolution and refresh rate), current emulated vblank period (16ms) may not always be correct and could lead to miss-sync behavior in guest. Guest driver will setup new resolution and program vregs accordingly and it should always follows GEN PRM. Based on the simulated display regs by GVT, it's safe to decode the actual refresh rate using by guest from vreg only. Current implementation only enables PIPE_A and PIPE_A is always tied to TRANSCODER_A in HW. GVT may simulate DP monitor on PORT_B or PORT_D based on the caller. So we can find out which DPLL is used by PORT_x which connected to TRANSCODER_A and calculate the DP bit rate from the DPLL frequency. Then DP stream clock (pixel clock) can be calculated from DP link M/N and DP bit rate. Finally, get the refresh rate from pixel clock, H total and V total. The per-vGPU accurate refresh rate is not used yet but only stored, until per-vGPU vblank timer is enabled. Then each vGPU can have different and accurate refresh rate per-guest driver configuration. Refer to PRM for GEN display and VESA timing standard for more details. V2: Rebase to 5.11. Correctly calculate DP link rate for BDW and BXT. Use GVT_DEFAULT_REFRESH_RATE instead of hardcoded to 60 as init refresh. Typo fix. (zhenyu) Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044559.283622-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-01-21Merge tag 'gvt-gt-next-2021-01-18' of https://github.com/intel/gvt-linux ↵Joonas Lahtinen
into drm-intel-gt-next gvt-gt-next-2021-01-18 - GVT cmd parser enhancement against guest context (Yan) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210118050739.GY15982@zhen-hp.sh.intel.com
2020-12-25drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCHYan Zhao
F_CMD_WRITE_PATCH means command write to this register needs to be patched Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034553.17272-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: make width of mmio_attribute biggerYan Zhao
8 bits are all used up. extend it to 16 bits to hold more flags. Suggested-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034545.17224-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-25drm/i915/gvt: parse init context to update cmd accessible reg whitelistYan Zhao
Logical Context is actually a big batch buffer consisting of multiple LRI commands + saved registers. It comprises Ring Context (the first 0x50 dwords) and Engine Context. The registers defined in Engine Context are command accessible, and safe to execute in VM Context. However, not all of them are currently tracked in existing register whitelist. Here we kick hardware to generate a dummy Engine Context and then scan the dummy Engine context to update whitelist dynamically. Based on updated list, later patches will audit future VM Engine Contexts to disallow undesired LRIs (if out of what hardware generates). Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Wang Zhi <zhi.a.wang@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201223034430.16934-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2020-12-22drm/i915/gvt: make gvt.h self-containedJani Nikula
Add necessary #includes and forward declarations to make the header compile on its own. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/dc4f4d498a39279d12096c1487a3c50d201e5e4f.1607422863.git.jani.nikula@intel.com
2020-11-23drm/i915/gvt: treat intel_gvt_mpt as const in gvt codeJulian Stecklina
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
2020-11-10drm/i915/gvt: Save/restore HW status to support GVT suspend/resumeColin Xu
This patch save/restore necessary GVT info during i915 suspend/resume so that GVT enabled QEMU VM can continue running. Only GGTT and fence regs are saved/restored now. GVT will save GGTT entries on each host_entry update, restore the saved dirty entries and re-init fence regs in resume routine. V2: - Change kzalloc/kfree to vzalloc/vfree since the space allocated from kmalloc may not enough for all saved GGTT entries. - Keep gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c and move the actual implementation to gvt.h/gvt.c. (zhenyu) - Check gvt config on and active with intel_gvt_active(). (zhenyu) V3: (zhenyu) - Incorrect copy length. Should be num entries * entry size. - Use memcpy_toio()/memcpy_fromio() instead of memcpy for iomem. - Add F_PM_SAVE flags to indicate which MMIOs to save/restore for PM. V4: Rebase. V5: Fail intel_gvt_save_ggtt as -ENOMEM if fail to alloc memory to save ggtt. Free allocated ggtt_entries on failure. V6: Save host entry to per-vGPU gtt.ggtt_mm on each host_entry update. V7: Restore GGTT entry based on present bit. Split fence restore and mmio restore in different functions. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201027045308.158955-1-colin.xu@intel.com
2020-11-10drm/i915/gvt: correct a false comment of flag F_UNALIGNYan Zhao
Correct falsely removed comment of flag F_UNALIGN. Fixes: a6c5817a38cf ("drm/i915/gvt: remove flag F_CMD_ACCESSED") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200910035405.20273-1-yan.y.zhao@intel.com
2020-09-14Merge tag 'gvt-next-2020-09-10' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-next-queued gvt-next-2020-09-10 - Cleanup command access flag (Yan) - New workaround cmd access fix (Colin) - MIA reset state fix (Colin) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910053720.GK28614@zhen-hp.sh.intel.com
2020-09-10drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESSYan Zhao
flag F_CMD_ACCESS represents whether an MMIO is able to be accessed by GPU commands. In this patch, 1. add interface to set this flag 2. rename intel_gvt_mmio_is_cmd_access() to intel_gvt_mmio_is_cmd_accessible() and update its description message. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811070233.3387-1-yan.y.zhao@intel.com
2020-09-10drm/i915/gvt: remove flag F_CMD_ACCESSEDYan Zhao
Flag F_CMD_ACCESSED is not used. just remove it. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811063744.3272-1-yan.y.zhao@intel.com
2020-09-10drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTXYan Zhao
F_IN_CTX is an inaccurate flag name, because people may wrongly think all MMIOs in context image are with this flag. But actually, this flag is only for MMIOs both in GVT's save-restore list and in hardare logical context's image. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811060944.3039-1-yan.y.zhao@intel.com
2020-07-29drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.Colin Xu
When system enters S3 state, device enters D3 state while RAM remains powered. From vGPU/GVT perspective, ppgtt_mm is residual in guest memory during vGPU in D3 state, so that when guest state transits from S3->S0, ppgtt_mm can be re-used and no need rebuild. Previous implementation invalidate and destroy ppgtt_mm at DMLR, regardless the power state transition is S0->S3->S0 (guest suspend or resume) or OFF->S0 (normal boot/reboot), invalidate and destroy ppgtt_mm is unnecessary in the former transition case. The patch saves the vGPU D3/D0 transition state when guest writes the PCI_PM_CTRL in vGPU's configure space, then in later DMLR, GVT can decide whether or not invalidate and destroy ppgtt_mm is required. The d3_entered flags is reset after DMLR. To test this feature, make sure S3 is enabled in QEMU parameters: i440fx: PIIX4_PM.disable_s3=0 q35: ICH9-LPC.disable_s3=0 Also need enable sleep option in guest OS if it's disabled. v2: - Revise commit message to more accurate description. (Kevin) - Split patch by logic. (Zhenyu) Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200709071002.247960-2-colin.xu@intel.com
2020-04-17drm/i915/gvt: skip populate shadow context if guest context not changedYan Zhao
Software is not expected to populate engine context except when using restore inhibit bit or golden state to initialize it for the first time. Therefore, if a newly submitted guest context is the same as the last shadowed one, no need to populate its engine context from guest again. Currently using lrca + ring_context_gpa to identify whether two guest contexts are the same. The reason of why context id is not included as an identifier is that i915 recently changed the code and context id is only unique for a context when OA is enabled. And when OA is on, context id is generated based on lrca. Therefore, in that case, if two contexts are of the same lrca, they have identical context ids as well. (This patch also works with old guest kernel like 4.20.) for guest context, if its ggtt entry is modified after last context shadowing, it is also deemed as not the same context as last shadowed one. v7: -removed local variable "valid". use the one in s->last_ctx diretly v6: -change type of lrca of last ctx to be u32. as currently it's all protected by vgpu lock (Kevin Tian) -reset valid of last ctx to false once it needs to be repopulated before population completes successfully (Kevin Tian) v5: -merge all 3 patches into one patch (Zhenyu Wang) v4: - split the series into 3 patches. - don't turn on optimization until last patch in this series (Kevin Tian) - define lrca to be atomic in this patch rather than update its type in the second patch (Kevin Tian) v3: updated commit message to describe engine context and context id clearly (Kevin Tian) v2: rebased to 5.6.0-rc4+Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Suggested-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200417091334.32628-1-yan.y.zhao@intel.com
2020-03-06drm/i915/gvt: Wean gvt off using dev_privChris Wilson
Teach gvt to use intel_gt directly as it currently assumes direct HW access. [Zhenyu: rebase, fix compiling] Cc: Ding Zhuocheng <zhuocheng.ding@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-3-zhenyuw@linux.intel.com
2020-02-20drm/i915/gvt: make gvt oblivious of kvmgt data structuresJulian Stecklina
Instead of defining KVMGT per-device state in struct intel_vgpu directly, add an indirection. This makes the GVT code oblivious of what state KVMGT needs to keep. The intention here is to eventually make it possible to build hypervisor backends for the mediator, without having to touch the mediator itself. This is a first step. v2: - rebased onto gvt-staging (no conflicts) Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200217163858.26496-1-julian.stecklina@cyberus-technology.de
2020-01-20drm/i915/gvt: remove unused vblank_done completionJulian Stecklina
This variable is used nowhere, so remove it. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-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/20200109171357.115936-3-julian.stecklina@cyberus-technology.de
2019-12-11drm/i915/gvt: remove unused type attributesZhenyu Wang
Only need to get attribute group instead of attributes and it has no use, so remove it. Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191202070109.73924-1-zhenyuw@linux.intel.com
2019-08-13drm/i915/gvt: factor out tlb and mocs register offset tableZhi Wang
Factor out tlb and mocs register offset table to fix the issues reported by klocwork, #512 and #550. Mostly, the reason why the klocwork reports these problems is because there can be possbilities for platforms, which have more rings than the ring offset table, to take the dirty data from the stack as the register offset. It results to a random HW register offset writting in this scenairo when doing context switch between vGPUs. After the factoring, the ring offset table of TLB and MOCS should be per platform. v2: - Enable TLB register switch for GEN8. (Zhenyu) Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-08-13drm/i915/gvt: no need to check return value of debugfs_create functionsGreg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Because there is no need to check these functions, a number of local functions can be made to return void to simplify things as nothing can fail. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gvt-dev@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-06-14drm/i915: update rpm_get/put to use the rpm structureDaniele Ceraolo Spurio
The functions where internally already only using the structure, so we need to just flip the interface. v2: rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-7-daniele.ceraolospurio@intel.com
2019-06-13drm/i915: Move fence register tracking from i915->mm to ggttChris Wilson
As the fence registers only apply to regions inside the GGTT is makes more sense that we track these as part of the i915_ggtt and not the general mm. In the next patch, we will then pull the register locking underneath the i915_ggtt.mutex. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613073254.24048-1-chris@chris-wilson.co.uk
2019-04-26drm/i915/gvt: Pin the per-engine GVT shadow contextsChris Wilson
Our eventual goal is to rid request construction of struct_mutex, with the short term step of lifting the struct_mutex requirements into the higher levels (i.e. the caller must ensure that the context is already pinned into the GTT). In this patch, we pin GVT's shadow context upon allocation and so keep them pinned into the GGTT for as long as the virtual machine is alive, and so we can use the simpler request construction path safe in the knowledge that the hard work is already done. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426163336.15906-1-chris@chris-wilson.co.uk
2019-04-16Merge tag 'drm-intel-next-2019-04-04' into gvt-nextZhenyu Wang
Merge back drm-intel-next for engine name definition refinement and 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses") that would need gvt fixes to depend on. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-04-02drm/i915: Move intel_engine_mask_t around for use by i915_request_types.hChris Wilson
We want to use intel_engine_mask_t inside i915_request.h, which means extracting it from the general header file mess and placing it inside a types.h. A knock on effect is that the compiler wants to warn about type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare for the worst. v2: Use intel_engine_mask_t consistently v3: Move I915_NUM_ENGINES to its natural home at the end of the enum Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2019-03-11drm/i915/gvt: remove the unused sregYan Zhao
code cleanup. sreg is not used now. remove it for code cleanness. v3: remove unnecessary array_size in vreg's memory allocation (min he) v2: do not allocate memory for sreg. (min he) Reviewed-by: He, Min <min.he@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-18drm/i915/gvt: Use consist max display pipe numbers as i915 definitionColin Xu
GVT implements a homogeneous vGPU as host GPU so max vGPU display pipes can't exceed HW. The inconsistency definition has potential risks which could cause array indexing overflow. Remove the unnecessary define of INTEL_GVT_MAX_PIPE and align with i915. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-01Merge tag 'gvt-next-2019-02-01' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-next-queued gvt-next-2019-02-01 - new VFIO EDID region support (Henry) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190201061523.GE5588@zhen-hp.sh.intel.com
2019-01-31drm/i915/gvt: add hotplug emulationHang Yuan
Add function to emulate hotplug interrupt for SKL/KBL platforms Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-01-24Merge tag 'gvt-next-2019-01-24' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-next-queued gvt-next-2019-01-24 - split kvmgt as seperate module (Zhenyu) - Coffeelake GVT support (Fred) - const treatment and change for kernel type (Jani) Signed-off-by: Rodrigo Vivi <vivijim@rdvivi-cozumel.jf.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124054048.GO7203@zhen-hp.sh.intel.com
2019-01-14drm/i915: Markup paired operations on wakerefsChris Wilson
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-2-chris@chris-wilson.co.uk
2019-01-02drm/i915/gvt: Change KVMGT as self load moduleZhenyu Wang
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-07drm/i915/gvt: Fix shadow ctx ppgtt destroy functionXiong Zhang
Recently gvt shadow ctx create ppgtt table and this ppgtt's root pointer is modified at workload dispatch, then we lose the original ppgtt's root pointer, this causes the ppgtt destroy function abnormal as it will release the wrong root table. This patch save i915 context ppgtt root pointer at shadow ctx creation and restore it at shadow ctx destruction. v2: Split save and restore function (Zhenyu) Fixes:4f15665ccbba("drm/i915: Add ppgtt to GVT GEM context") Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-13drm/i915/gvt: free workload in vgpu releaseHang 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: 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-07-30BackMerge v4.18-rc7 into drm-nextDave Airlie
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-05drm/i915/gvt: update vreg on inhibit context lri commandHang Yuan
Commit cd7e 61b9"init mmio by lri command in vgpu inhibit context" initializes registers saved/restored in context with its vreg value through lri command in ring buffer. It relies on vreg got updated on every guest access. There is a case found that Linux guest uses lri command in inhibit-ctx to update the register. This patch adds vreg update on this case. v2: move mmio_attribute functions to gvt.h (Zhenyu) v3: use mask_mmio_write in vreg update v4: refine codes and add more comments (Zhenyu) Fixes: cd7e61b9("drm/i915/gvt: init mmio by lri command in vgpu inhibit context") Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-06-07Merge tag 'drm-intel-next-2018-06-06' into gvt-nextZhenyu Wang
Backmerge for recent request->hw_context change and new vGPU huge page capability definition. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-06-05drm/i915/gtt: Rename i915_hw_ppgtt base memberChris Wilson
In the near future, I want to subclass gen6_hw_ppgtt as it contains a few specialised members and I wish to add more. To avoid the ugliness of using ppgtt->base.base, rename the i915_hw_ppgtt base member (i915_address_space) as vm, which is our common shorthand for an i915_address_space local. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180605153758.18422-1-chris@chris-wilson.co.uk
2018-05-18drm/i915/gvt: Use sched_lock to protect gvt scheduler logic.Colin Xu
The scheduler lock(gvt->sched_lock) is used to protect gvt scheduler logic, including the gvt scheduler structure(gvt->scheduler and per vgpu schedule data(vgpu->sched_data, vgpu->sched_ctl). v9: - Change commit author since the patches are improved a lot compared with original version. Original author: Pei Zhang <pei.zhang@intel.com> - Rebase to latest gvt-staging. v8: - Correct coding wqstyle. - Rebase to latest gvt-staging. v7: - Remove gtt_lock since already proteced by gvt_lock and vgpu_lock. v6: - Rebase to latest gvt-staging. v5: - Rebase to latest gvt-staging. v4: - Rebase to latest gvt-staging. v3: update to latest code base Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-05-18drm/i915/gvt: Use vgpu_lock to protect per vgpu accessColin Xu
The patch set splits out 2 small locks from the original big gvt lock: - vgpu_lock protects per-vGPU data and logic, especially the vGPU trap emulation path. - sched_lock protects gvt scheudler structure, context schedule logic and vGPU's schedule data. Use vgpu_lock to replace the gvt big lock. By doing this, the mmio read/write trap path, vgpu virtual event emulation and other vgpu related process, would be protected under per vgpu_lock. v9: - Change commit author since the patches are improved a lot compared with original version. Original author: Pei Zhang <pei.zhang@intel.com> - Rebase to latest gvt-staging. v8: - Correct coding and comment style. - Rebase to latest gvt-staging. v7: - Remove gtt_lock since already proteced by gvt_lock and vgpu_lock. - Fix a typo in intel_gvt_deactivate_vgpu, unlock the wrong lock. v6: - Rebase to latest gvt-staging. v5: - Rebase to latest gvt-staging. - intel_vgpu_page_track_handler should use vgpu_lock. v4: - Rebase to latest gvt-staging. - Protect vgpu->active access with vgpu_lock. - Do not wait gpu idle in vgpu_lock. v3: update to latest code base v2: add gvt->lock in function gvt_check_vblank_emulation Performance comparison on Kabylake platform. - Configuration: Host: Ubuntu 16.04. Guest 1 & 2: Ubuntu 16.04. glmark2 score comparison: - Configuration: Host: glxgears. Guests: glmark2. +--------------------------------+-----------------+ | Setup | glmark2 score | +--------------------------------+-----------------+ | unified lock, iommu=on | 58~62 (avg. 60) | +--------------------------------+-----------------+ | unified lock, iommu=igfx_off | 57~61 (avg. 59) | +--------------------------------+-----------------+ | per-logic lock, iommu=on | 60~68 (avg. 64) | +--------------------------------+-----------------+ | per-logic lock, iommu=igfx_off | 61~67 (avg. 64) | +--------------------------------+-----------------+ lock_stat comparison: - Configuration: Stop lock stat immediately after boot up. Boot 2 VM Guests. Run glmark2 in guests. Start perf lock_stat for 20 seconds and stop again. - Legend: c - contentions; w - waittime-avg +------------+-----------------+-----------+---------------+------------+ | | gvt_lock |sched_lock | vgpu_lock | gtt_lock | + lock type; +-----------------+-----------+---------------+------------+ | iommu set | c | w | c | w | c | w | c | w | +------------+-------+---------+----+------+------+--------+-----+------+ | unified; | 20697 | 839 |N/A | N/A | N/A | N/A | N/A | N/A | | on | | | | | | | | | +------------+-------+---------+----+------+------+--------+-----+------+ | unified; | 21838 | 658.15 |N/A | N/A | N/A | N/A | N/A | N/A | | igfx_off | | | | | | | | | +------------+-------+---------+----+------+------+--------+-----+------+ | per-logic; | 1553 | 1599.96 |9458|429.97| 5846 | 274.33 | 0 | 0.00 | | on | | | | | | | | | +------------+-------+---------+----+------+------+--------+-----+------+ | per-logic; | 1911 | 1678.32 |8335|445.16| 5451 | 244.80 | 0 | 0.00 | | igfx_off | | | | | | | | | +------------+-------+---------+----+------+------+--------+-----+------+ Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-05-14drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio with ↵Changbin Du
debug level The disable_warn_untrack never prevent gvt from printing untracked mmio errors. We were disturbed by this error storm and the fix is just adding them to the list with no essential new change. This message is only useful for enabling new platform during developing process. So lower the message level to debug and then remove disable_warn_untrack. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-04-23drm/i915/gvt: scan non-privileged batch buffer for debug purposeZhao Yan
For perfomance purpose, scanning of non-privileged batch buffer is turned off by default. But for debugging purpose, it can be turned on via debugfs. After scanning, we submit the original non-privileged batch buffer into hardware, so that the scanning is only a peeking window of guest submitted commands and will not affect the execution results. v4: - refine debugfs print format&content (zhenyu wang) - print engine id instread of engine name to prevent potential memory leak in debugfs warning message. (zhenyu wang) v3: - change vgpu->scan_nonprivbb from type bool to u32, so it is able to selectively turn on/off scanning of non-privileged batch buffer on engine level. e.g. if vgpu->scan_nonprivbb=3, then it will scan non-privileged batch buffer on engine 0 and 1. - in debugfs interface to set vgpu->scan_nonprivbb, print warning message to warn user and explicitly tell state change in kernel log (zhenyu wang) v2: - rebase - update comments for start_gma_offset (henry) Signed-off-by: Zhao Yan <yan.y.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
2018-03-06drm/i915/kvmgt: Add kvmgt debugfs entry nr_cache_entries under vgpuChangbin Du
Add a new debugfs entry kvmgt_nr_cache_entries under vgpu which shows the number of entry in dma cache. $ cat /sys/kernel/debug/gvt/vgpu1/kvmgt_nr_cache_entries 10101 v3: fix compiling error for some configuration. (Xiong Zhang <xiong.y.zhang@intel.com>) v2: keep debugfs layout flat. 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 Du
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>
generated by cgit v1.2.3-70-g09d2 (git 2.47.1) at 2025-01-24 14:30:53 +0000