Re: [PATCH] drm/i915: Check ppgtt validity for GVT GEM context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Zhenyu Wang (2018-10-11 03:45:07)
> On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> > The guest couldn't boot up under GVT-g environment as the following call
> > trace exists:
> > [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
> > [  272.504834] Call Trace:
> > [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> > [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> > [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> > [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> > [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> > [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> > [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> > [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> > [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > 
> > GVT GEM context is created by i915_gem_context_create_gvt() which doesn't
> > allocate ppgtt. So GVT GEM context structure doesn't have a valid
> > i915_hw_ppgtt.
> > 
> > GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> > ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto gpu.
> > The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of gvt
> > refactor work should be done in order to use i915_hw_ppgtt structure.
> > So let's fix the regression first.
> > 
> > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for execlists")
> > 
> > Signed-off-by: Xiong Zhang <xiong.y.zhang@xxxxxxxxx>
> > ---
> 
> Chris, any comment? Without this, current gvt breaks on drm tip with kernel oops.
> Could we fix the regression first then check gvt ctx stub ppgtt handling later?
> Which would require more change on gvt side, not sure if need any more helper from
> i915 ppgtt code with a clean fix..

We both thought this wasn't the approach we wanted to take. My position
is that this leaves the registers ostensibly programmed to garbage.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux