summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gvt/gvt.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/gvt: use atomic operations to change the vGPU statusZhi Wang2023-01-041-5/+10
| | | | | | | | | | | | | | | | | Several vGPU status are used to decide the availability of GVT-g core logics when creating a vGPU. Use atomic operations on changing the vGPU status to avoid the racing. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: intel-gvt-dev@lists.freedesktop.org Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20221110122034.3382-2-zhi.a.wang@intel.com
* Merge tag 'gvt-next-2022-11-17' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi2022-11-171-2/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | drm-intel-next gvt-next-2022-11-17 - kernel doc fixes - remove vgpu->released sanity check - small clean up Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221117064106.GT30028@zhen-hp.sh.intel.com
| * drm/i915/gvt: remove the vgpu->released and its sanity checkZhi Wang2022-11-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The life cycle of a vGPU, which is represented by a vfio_device, has been managed by the VFIO core logic. Remove the vgpu->released, which was used for a sanity check on the removal path of the vGPU instance. The sanity check has already been covered in the VFIO core logic. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: intel-gvt-dev@lists.freedesktop.org Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20221104145652.1570-1-zhi.a.wang@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
* | vfio/mdev: consolidate all the available_instance sysfs into the core codeChristoph Hellwig2022-10-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Every driver just print a number, simply add a method to the mdev_driver to return it and provide a standard sysfs show function. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Link: https://lore.kernel.org/r/20220923092652.100656-13-hch@lst.de Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* | vfio/mdev: simplify mdev_type handlingChristoph Hellwig2022-10-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of abusing struct attribute_group to control initialization of struct mdev_type, just define the actual attributes in the mdev_driver, allocate the mdev_type structures in the caller and pass them to mdev_register_parent. This allows the caller to use container_of to get at the containing structure and thus significantly simplify the code. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Link: https://lore.kernel.org/r/20220923092652.100656-6-hch@lst.de Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* | vfio/mdev: embedd struct mdev_parent in the parent data structureChristoph Hellwig2022-10-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify mdev_{un}register_device by requiring the caller to pass in a structure allocate as part of the parent device structure. This removes the need for a list of parents and the separate mdev_parent refcount as we can simplify rely on the reference to the parent device. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Link: https://lore.kernel.org/r/20220923092652.100656-5-hch@lst.de Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* | drm/i915/gvt: simplify vgpu configuration managementChristoph Hellwig2022-10-041-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of copying the information from the vgpu_types arrays into each intel_vgpu_type structure, just reference this constant information with a pointer to the already existing data structure, and pass it into the low-level VGPU creation helpers intead of copying the data into yet anothe params data structure. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://lore.kernel.org/r/20220923092652.100656-3-hch@lst.de [aw: Fold fix from 20220928121110.GA30738@lst.de] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* | drm/i915/gvt: Use the new device life cycle helpersKevin Tian2022-09-211-3/+2
|/ | | | | | | | | | | | | | Move vfio_device to the start of intel_vgpu as required by the new helpers. Change intel_gvt_create_vgpu() to use intel_vgpu as the first param as other vgpu helpers do. Signed-off-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://lore.kernel.org/r/20220921104401.38898-9-kevin.tian@intel.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* vfio: Replace the DMA unmapping notifier with a callbackJason Gunthorpe2022-07-201-1/+0
| | | | | | | | | | | | | | | | Instead of having drivers register the notifier with explicit code just have them provide a dma_unmap callback op in their driver ops and rely on the core code to wire it up. Suggested-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* vfio: remove VFIO_GROUP_NOTIFY_SET_KVMMatthew Rosato2022-05-241-3/+0
| | | | | | | | | | | | | | | | | | | Rather than relying on a notifier for associating the KVM with the group, let's assume that the association has already been made prior to device_open. The first time a device is opened associate the group KVM with the device. This fixes a user-triggerable oops in GVT. Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://lore.kernel.org/r/20220519183311.582380-2-mjrosato@linux.ibm.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pagesJason Gunthorpe2022-05-111-1/+0
| | | | | | | | | | | | | | | Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no reason to use a group interface here, kvmgt has easy access to a vfio_device. Delete kvmgt_vdev::vfio_group since these calls were the last users. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://lore.kernel.org/r/5-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw()Jason Gunthorpe2022-05-111-2/+2
| | | | | | | | | | | | | | Every caller has a readily available vfio_device pointer, use that instead of passing in a generic struct device. Change vfio_dma_rw() to take in the struct vfio_device and move the container users that would have been held by vfio_group_get_external_user_from_dev() to vfio_dma_rw() directly, like vfio_pin/unpin_pages(). Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/4-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
* drm/i915/gvt: merge gvt.c into kvmgvt.cChristoph Hellwig2022-04-211-6/+0
| | | | | | | | | | | The code in both files is deeply interconnected, so merge it and keep a bunch of structures and functions static. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-30-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: convert to use vfio_register_emulated_iommu_devChristoph Hellwig2022-04-211-1/+1
| | | | | | | | | | | | | | This is straightforward conversion, the intel_vgpu already has a pointer to the vfio_dev, which can be replaced with the embedded structure and we can replace all the mdev_get_drvdata() with a simple container_of(). Based on an patch from Jason Gunthorpe. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-29-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: remove the extra vfio_device refcounting for dmabufsChristoph Hellwig2022-04-211-1/+0
| | | | | | | | | | | | | All the dmabufs are torn down when th VGPU is released, so there is no need for extra refcounting here. Based on an patch from Jason Gunthorpe. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-25-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: remove struct intel_gvt_mptChristoph Hellwig2022-04-211-8/+4
| | | | | | | | | | | Just call the initializion and exit functions directly and remove this abstraction entirely. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-24-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize dma_pin_guest_pageChristoph Hellwig2022-04-211-0/+1
| | | | | | | | | | Just call the function directly and remove a pointless wrapper. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-23-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize ->dma_{,un}map_guest_pageChristoph Hellwig2022-04-211-0/+4
| | | | | | | | | | Just call the functions directly. Also remove a pointless wrapper. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-22-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize ->{enable,disable}_page_trackChristoph Hellwig2022-04-211-0/+3
| | | | | | | | | | Just call the kvmgt functions directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-21-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize ->detach_vgpuChristoph Hellwig2022-04-211-0/+1
| | | | | | | | | | Just call the function directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-17-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize ->set_edid and ->set_opregionChristoph Hellwig2022-04-211-0/+3
| | | | | | | | | | Just call the code to setup the opregions and EDID data directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-16-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: devirtualize ->{read,write}_gpaChristoph Hellwig2022-04-211-0/+37
| | | | | | | | | | | Just call the VFIO functions directly instead of through the method table. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-14-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: remove vgpu->handleChristoph Hellwig2022-04-211-2/+1
| | | | | | | | | | | Always pass the actual vgpu structure instead of encoding it as a "handle" and add a bool flag to denote if a VGPU is attached. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-13-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpuChristoph Hellwig2022-04-211-0/+8
| | | | | | | | | | Consolidate the per-VGPU structures into a single one. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-12-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpuChristoph Hellwig2022-04-211-8/+23
| | | | | | | | | | Move towards having only a single structure for the per-VGPU state. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-11-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: remove intel_gvt_opsChristoph Hellwig2022-04-211-24/+0
| | | | | | | | | | | Remove these pointless indirect alls by just calling the only instance of each method directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-8-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: move the gvt code into kvmgt.koChristoph Hellwig2022-04-211-4/+2
| | | | | | | | | | | | | | Instead of having an option to build the gvt code into the main i915 module, just move it into the kvmgt.ko module. This only requires a new struct with three entries that the KVMGT modules needs to register with the main i915 module, and a proper list of GVT-enabled devices instead of global device pointer. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-7-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: remove enum hypervisor_typeChristoph Hellwig2022-04-211-1/+0
| | | | | | | | | | | The only supported hypervisor is KVM, so don't bother with dead code enumerating hypervisors. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-3-hch@lst.de Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* i915/gvt: Separate the MMIO tracking table from GVT-gZhi Wang2022-04-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO tracking table needs to be separated from GVT-g. v9: - Fix a problem might cause kernel panic. - Remove the redaundant definitation of intel_get_device_type(). (Jani) - Sort the list of header reference in intel_gvt_mmio.c (Jani) - Include minimum header insted in intel_gvt_mmio.c (Jani) v8: - Use SPDX header in the intel_gvt_mmio_table.c - Reference the gvt.h with path. (Jani) - Add a missing fix on mmio emulation path during the debug. - Fix a building problem on refreshed gvt-staging branch. (Christoph) v7: - Keep the marcos of device generation in GVT-g. (Christoph, Jani) v6: - Move the mmio_table.c into i915. (Christoph) - Keep init_device_info and related structures in GVT-g. (Christoph) - Refine the callbacks of the iterator. (Christoph) - Move the flags of MMIO register defination to GVT-g. (Chrsitoph) - Move the mmio block handling to GVT-g. v5: - Re-design the mmio table framework. (Christoph) v4: - Fix the errors of patch checking scripts. v3: - Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani) v2: - Implement a mmio table instead of generating it by marco in i915. (Jani) Cc: Christoph Hellwig <hch@lst.de> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Vivi Rodrigo <rodrigo.vivi@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220407071945.72148-2-zhi.a.wang@intel.com
* drm/i915/gvt: Constify gvt_mmio_blockRikard Falkeborn2022-01-121-1/+1
| | | | | | | | | | These are never modified, so make them const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211204105527.15741-6-rikard.falkeborn@gmail.com Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
* drm/i915/gvt: Move mdev attribute groups into kvmgt moduleZhenyu Wang2021-05-171-3/+0
| | | | | | | | | | | | | | | | | | 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
* Merge tag 'vfio-v5.13-rc1' of git://github.com/awilliam/linux-vfioLinus Torvalds2021-04-281-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * vfio/gvt: Use mdev_get_type_group_id()Jason Gunthorpe2021-04-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'gvt-next-2021-03-16' of https://github.com/intel/gvt-linux into ↵Jani Nikula2021-03-161-4/+9
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | 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
| * drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual displayColin Xu2021-03-011-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vregColin Xu2021-03-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'gvt-gt-next-2021-01-18' of https://github.com/intel/gvt-linux ↵Joonas Lahtinen2021-01-211-1/+36
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 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
| * drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCHYan Zhao2020-12-251-0/+31
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915/gvt: make width of mmio_attribute biggerYan Zhao2020-12-251-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915/gvt: parse init context to update cmd accessible reg whitelistYan Zhao2020-12-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915/gvt: make gvt.h self-containedJani Nikula2020-12-221-0/+4
| | | | | | | | | | | | | | | | | | | | 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
* | drm/i915/gvt: treat intel_gvt_mpt as const in gvt codeJulian Stecklina2020-11-231-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
* | drm/i915/gvt: Save/restore HW status to support GVT suspend/resumeColin Xu2020-11-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | drm/i915/gvt: correct a false comment of flag F_UNALIGNYan Zhao2020-11-101-1/+1
|/ | | | | | | | | | 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
* Merge tag 'gvt-next-2020-09-10' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi2020-09-141-19/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESSYan Zhao2020-09-101-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * drm/i915/gvt: remove flag F_CMD_ACCESSEDYan Zhao2020-09-101-14/+0
| | | | | | | | | | | | | | | | | | 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
| * drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTXYan Zhao2020-09-101-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.Colin Xu2020-07-291-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/gvt: skip populate shadow context if guest context not changedYan Zhao2020-04-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
View Lorry Controller Status