Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 4月, 2017 1 次提交
  3. 01 4月, 2017 1 次提交
  5. 30 3月, 2017 2 次提交
    • C
      drm/i915/gvt: exclude cfg space from failsafe mode · f8572690
      由 Changbin Du 提交于 
      When test GVTg as below scenario:
  VM boot --> failsafe --> kill qemu --> VM boot.
Qemu report error at the second boot:
  ERROR: PCI region size must be pow2 type=0x0, size=0x1fa1000

Qemu need access PCI_ROM_ADDRESS reg to determine the size of expansion
PCI rom. The mechanism just like the BAR reg (write-read) and we should
return the size 0 since we have no rom. If we reject the write to
PCI_ROM_ADDRESS, Qemu cannot get the correct size of rom.

Essentially, GVTg failsafe mode should not break PCI function. So we
exclude cfg space from failsafe mode. This can fix above issue.

v2: add Fixes and Bugzilla link.

Fixes: fd64be63 ("drm/i915/gvt: introduced failsafe mode into vgpu")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100296Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      f8572690
    • Z
      drm/i915/gvt: Activate/de-activate vGPU in mdev ops. · b79c52ae
      由 Zhi Wang 提交于 
      This patch introduces two functions for activating/de-activating vGPU in
mdev ops.

A racing condition was found between virtual vblank emulation and KVGMT
mdev release path. V-blank emulation will emulate and inject V-blank
interrupt for every active vGPU with holding gvt->lock, while in mdev
release path, it will directly release hypervisor handle without changing
vGPU status or taking gvt->lock, so a kernel oops is encountered when
vblank emulation is injecting a interrupt with a invalid hypervisor
handle. (Reported by Terrence)

To solve this problem, we factor out vGPU activation/de-activation from
vGPU creation/destruction path and let KVMGT mdev release ops de-activate
the vGPU before release hypervisor handle. Once a vGPU is de-activated,
GVT-g will not emulate v-blank for it or touch the hypervisor handle.

Fixes: 659643f7 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      b79c52ae
  7. 22 3月, 2017 1 次提交
    • C
      drm/i915/gvt: Use force single submit flag to distinguish gvt request from i915 request · bc2d4b62
      由 Changbin Du 提交于 
      In my previous Commit ab9da627906a ("drm/i915: make context status
notifier head be per engine") rely on scheduler->current_workload[x]
to distinguish gvt spacial request from i915 request. But this is
not always true since no synchronization between workload_thread and
lrc irq handler.

    lrc irq handler               workload_thread
         ----                          ----
  pick i915 requests;
                                intel_vgpu_submit_execlist();
                                current_workload[x] = xxx;
  shadow_context_status_change();

Then current_workload[x] is not null but current request is of i915 self.
So instead we check ctx flag CONTEXT_FORCE_SINGLE_SUBMISSION. Only gvt
request set this flag and always set.

v2: Reverse the order of multi-condition 'if' statement.

Fixes: ab9da6279 ("drm/i915: make context status notifier head be per engine")
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Reviewed-by: NYulei Zhang <yulei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      bc2d4b62
  9. 21 3月, 2017 3 次提交
  11. 20 3月, 2017 2 次提交
    • P
      drm/i915/gvt: add write handler for mmio mbctl · 975629c3
      由 Pei Zhang 提交于 
      Guest will write mmio mbctl which need a special handler in gvt to
clear the bit 4 to inidcate the write operation success.

V2: use bit definition macro to make code readable.
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      975629c3
    • A
      drm/i915/kvmgt: Hold struct kvm reference · 93a15b58
      由 Alex Williamson 提交于 
      The kvmgt code keeps a pointer to the struct kvm associated with the
device, but doesn't actually hold a reference to it.  If we do unclean
shutdown testing (ie. killing the user process), then we can see the
kvm association to the device unset, which causes kvmgt to trigger a
device release via a work queue.  Naturally we cannot guarantee that
the cached struct kvm pointer is still valid at this point without
holding a reference.  The observed failure in this case is a stuck
cpu trying to acquire the spinlock from the invalid reference, but
other failure modes are clearly possible.  Hold a reference to avoid
this.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: stable@vger.kernel.org #v4.10
Cc: Jike Song <jike.song@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      93a15b58
  13. 17 3月, 2017 8 次提交
  15. 08 3月, 2017 1 次提交
  17. 06 3月, 2017 2 次提交
    • C
      drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration space · c2e04fda
      由 Changbin Du 提交于 
      Per PCI specification, Configuration Register has different types (RO,
RW, RW1C, Rsvd). For RO Register bits are read-only and cannot be
altered by software. For RW1C Register bits indicate status when read.
A Set bit indicates a status event which is Cleared by writing a 1b.
Writing a 0b to RW1C bits has no effect. Reserved Register is for future
implementations, and they are read-only and must return zero when read.

Current vGPU configuration write emulation just copy the value as it is.
So we haven't emulated RO, RW1C and Rsvd Registers correctly. This patch
is following the Spec to correct emulation logic. We add a function
vgpu_cfg_mem_write to wrap the access to vGPU configuration memory.
The write function uses a RW Register bitmap to avoid RO bits be
overwritten, and emulate RW1C behavior for the particular status Register.

v2:
  new = src[i] --> new = src[i] & mask (zhenyu)
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Cc: Xiaoguang Chen <xiaoguang.chen@intel.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Cc: Min He <min.he@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      c2e04fda
    • C
      drm/i915/gvt: handle workload lifecycle properly · 8f1117ab
      由 Chuanxiao Dong 提交于 
      Currently i915 has a request replay mechanism which can make sure
the request can be replayed after a GPU reset. With this mechanism,
gvt should wait until the GVT request seqno passed before complete
the current workload. So that there should be a context switch interrupt
come before gvt free the workload. In this way, workload lifecylce
matches with the i915 request lifecycle. The workload can only be freed
after the request is completed.

v2: use gvt_dbg_sched instead of gvt_err to print when wait again
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      8f1117ab
  19. 02 3月, 2017 1 次提交
  21. 01 3月, 2017 5 次提交
  23. 24 2月, 2017 4 次提交
  25. 23 2月, 2017 9 次提交