1. 08 Sep, 2017 11 commits
    • Jani Nikula's avatar
      Merge tag 'gvt-next-2017-09-08' of https://github.com/01org/gvt-linux into drm-intel-next-queued · 6af5d670
      Jani Nikula authored
      gvt-next-2017-09-08
      
      - PCI config sanitize series (Changbin)
      - Workload submission error handling series (Fred)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170908063155.l54lvpivxntjm7hq@zhen-hp.sh.intel.com
      6af5d670
    • Changbin Du's avatar
      drm/i915/gvt: Add support for PCIe extended configuration space · 02d578e5
      Changbin Du authored
      IGD is PCIe device and has extended configuration space. Checking
      the binary dump, we can see we have Caps located out of PCI compatible
      Configuration Space range.
      
      0x000: 86 80 12 19 17 04 10 00 06 00 00 03 00 00 00 00
      0x010: 04 00 00 10 08 00 00 00 0c 00 00 00 08 00 00 00
      0x020: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 b9 06
      0x030: 00 f8 ff ff 40 00 00 00 00 00 00 00 0b 01 00 00
      0x040: 09 70 0c 01 71 26 01 62 c8 00 04 84 00 00 00 00
      0x050: c1 00 00 00 39 00 00 00 00 00 00 00 01 00 00 a2
      0x060: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x070: 10 ac 92 00 00 80 00 10 00 00 00 00 00 00 00 00
      0x080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0a0: 00 00 00 00 00 00 00 00 00 00 00 00 05 d0 01 00
      0x0b0: 18 00 e0 fe 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0d0: 01 00 22 00 00 80 00 00 00 00 00 00 00 00 00 00
      0x0e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00
      0x0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100: 1b 00 01 20 02 14 00 00 00 00 00 00 00 00 00 00
      ...
      
      Currently, we only emulate the PCI compatible Configuration Space.
      This is okay if we attach vGPU to PCI bus. But when we attach to
      a PCI Express bus (when Qemu emulates a Intel Q35 chipset which has
      PCIe slot), it will not work. Extended Configuration Space is required
      for a PCIe device.
      
      This patch extended the virtual configuration space from 256 bytes
      to 4KB bytes. So we are to be a *real* PCIe device. And for the
      Extended CapList we keep same to physical GPU.
      
      Cc: Laszlo Ersek <lersek@redhat.com>
      Tested-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      02d578e5
    • Changbin Du's avatar
      drm/i915/gvt: Fix incorrect PCI BARs reporting · f1751362
      Changbin Du authored
      Looking at our virtual PCI device, we can see surprising Region 4 and Region 5.
      00:10.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 06) (prog-if 00 [VGA controller])
              ....
              Region 0: Memory at 140000000 (64-bit, non-prefetchable) [size=16M]
              Region 2: Memory at 180000000 (64-bit, prefetchable) [size=1G]
              Region 4: Memory at <ignored> (32-bit, non-prefetchable)
              Region 5: Memory at <ignored> (32-bit, non-prefetchable)
              Expansion ROM at febd6000 [disabled] [size=2K]
      
      The fact is that we only implemented BAR0 and BAR2. Surprising Region 4 and
      Region 5 are shown because we report their size as 0xffffffff. They should
      report size 0 instead.
      
      BTW, the physical GPU has a PIO BAR. GVTg hasn't implemented PIO access, so
      we ignored this BAR for vGPU device.
      
      v2: fix BAR size value calculation.
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458032Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      f1751362
    • fred gao's avatar
      drm/i915/gvt: Refine error handling for perform_bb_shadow · 1e3197d6
      fred gao authored
      fix the wrong return type and return error once the unknown
      command is scanned.
      
      v2:
      - separate this error handle from healthy rating code. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      1e3197d6
    • fred gao's avatar
      drm/i915/gvt: Refine error handling in dispatch_workload · 0f43702a
      fred gao authored
      When an error occurs in dispatch_workload, this patch is to do the
      proper cleanup and rollback to the original states before the workload
      is abandoned.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - original PTR_ERR(cs) is good and code cleanup. (Zhenyu)
      
      v4:
      - reuse the existing i915_add_request for error handling. (Zhenyu)
      
      v5:
      - remove the duplicate error handling release_shadow_wa_ctx and
        move the engine->context_unpin upper. (Zhenyu)
      
      v6:
      - keep the old label "out". (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0f43702a
    • fred gao's avatar
      drm/i915/gvt: Refine error handling for intel_vgpu_pin_mm · 46b441ef
      fred gao authored
      When it is failed in shadow_mm, the pin_count should rollback
      to the original states before return.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
        increase the pincount after shadow success. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      46b441ef
    • fred gao's avatar
      drm/i915/gvt: Refine error handling for prepare_execlist_workload · 0cce2823
      fred gao authored
      refine the error handling for prepare_execlist_workload to restore to the
      original states once error occurs.
      
      only release the shadowed batch buffer and wa ctx when the workload is
      completed successfully.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - handle prepare batch buffer/wa ctx pin errors and
      - emulate_schedule_in null issue. (Zhenyu)
      
      v4:
      - no need to handle emulate_schedule_in null issue. (Zhenyu)
      
      v5:
      - release the shadowed batch buffer and wa ctx only for the
        successful workload. (Zhenyu)
      
      v6:
      - polish the return style. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0cce2823
    • fred gao's avatar
      drm/i915/gvt: Add error handling for intel_gvt_scan_and_shadow_workload · a3cfdca9
      fred gao authored
      When an error occurs after shadow_indirect_ctx, this patch is to do the
      proper cleanup and rollback to the original states for shadowed indirect
      context before the workload is abandoned.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - no return check for clean up functions. (Changbin)
      
      v4:
      - expose and reuse the existing release_shadow_wa_ctx. (Zhenyu)
      
      v5:
      - move the release function to scheduler.c file. (Zhenyu)
      
      v6:
      - move error handling code of intel_gvt_scan_and_shadow_workload
        to here. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      a3cfdca9
    • fred gao's avatar
      drm/i915/gvt: Separate cmd scan from request allocation · 0a53bc07
      fred gao authored
      Currently i915 request structure and shadow ring buffer are allocated
      before command scan, so it will have to restore to previous states once
      any error happens afterwards in the long dispatch_workload path.
      
      This patch is to introduce a reserved ring buffer created at the beginning
      of vGPU initialization. Workload will be coped to this reserved buffer and
      be scanned first, the i915 request and shadow ring buffer are only
      allocated after the result of scan is successful.
      
      To balance the memory usage and buffer alloc time, the coming bigger ring
      buffer will be reallocated and kept until more bigger buffer is coming.
      
      v2:
      - use kmalloc for the smaller ring buffer, realloc if required. (Zhenyu)
      
      v3:
      - remove the dynamically allocated ring buffer. (Zhenyu)
      
      v4:
      - code style polish.
      - kfree previous allocated buffer once kmalloc failed. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0a53bc07
    • Changbin Du's avatar
      drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach · f090a00d
      Changbin Du authored
      For vfio-pci, if the region support MMAP then it should support both
      mmap and normal file access. The user-space is free to choose which is
      being used. For qemu, we just need add 'x-no-mmap=on' for vfio-pci
      option.
      
      Currently GVTg only support MMAP for BAR2. So GVTg will not work when
      user turn on x-no-mmap option.
      
      This patch added file style access for BAR2, aka the GPU aperture. We
      map the entire aperture partition of active vGPU to kernel space when
      guest driver try to enable PCI Memory Space. Then we redirect the file
      RW operation from kvmgt to this mapped area.
      
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458032Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      f090a00d
    • Changbin Du's avatar
      drm/i915/kvmgt: Sanitize PCI bar emulation · 5d5fe176
      Changbin Du authored
      For PCI, 64bit bar consumes two BAR registers, but this doesn't mean
      both of two BAR are valid. Actually the second BAR is regarded as
      reserved in this case. So we shouldn't emulate the second BAR.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      5d5fe176
  2. 07 Sep, 2017 24 commits
  3. 06 Sep, 2017 5 commits