linux-kernel - Re: linux-next: manual merge of the drm-intel tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Mar 2018 11:50:18 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     DRI <dri-devel@...ts.freedesktop.org>,
        Dave Airlie <airlied@...ux.ie>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        Intel Graphics <intel-gfx@...ts.freedesktop.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Min He <min.he@...el.com>, Zhi Wang <zhi.a.wang@...el.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>
Subject: Re: linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all,

On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/scheduler.c
> 
> between commit:
> 
>   fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> 
> from Linus' tree and commit:
> 
>   b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
> 
> from the drm-intel tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
> index 068126404151,a55b4975c154..000000000000
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
>   		pdp_pair[i].val = pdp[7 - i];
>   }
>   
>  +/*
>  + * when populating shadow ctx from guest, we should not overrride oa related
>  + * registers, so that they will not be overlapped by guest oa configs. Thus
>  + * made it possible to capture oa data from host for both host and guests.
>  + */
>  +static void sr_oa_regs(struct intel_vgpu_workload *workload,
>  +		u32 *reg_state, bool save)
>  +{
>  +	struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
>  +	u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>  +	u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>  +	int i = 0;
>  +	u32 flex_mmio[] = {
>  +		i915_mmio_reg_offset(EU_PERF_CNTL0),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL1),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL2),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL3),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL4),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL5),
>  +		i915_mmio_reg_offset(EU_PERF_CNTL6),
>  +	};
>  +
>  +	if (!workload || !reg_state || workload->ring_id != RCS)
>  +		return;
>  +
>  +	if (save) {
>  +		workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>  +
>  +		for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
>  +			u32 state_offset = ctx_flexeu0 + i * 2;
>  +
>  +			workload->flex_mmio[i] = reg_state[state_offset + 1];
>  +		}
>  +	} else {
>  +		reg_state[ctx_oactxctrl] =
>  +			i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>  +		reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
>  +
>  +		for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
>  +			u32 state_offset = ctx_flexeu0 + i * 2;
>  +			u32 mmio = flex_mmio[i];
>  +
>  +			reg_state[state_offset] = mmio;
>  +			reg_state[state_offset + 1] = workload->flex_mmio[i];
>  +		}
>  +	}
>  +}
>  +
> + static void update_shadow_pdps(struct intel_vgpu_workload *workload)
> + {
> + 	struct intel_vgpu *vgpu = workload->vgpu;
> + 	int ring_id = workload->ring_id;
> + 	struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
> + 	struct drm_i915_gem_object *ctx_obj =
> + 		shadow_ctx->engine[ring_id].state->obj;
> + 	struct execlist_ring_context *shadow_ring_context;
> + 	struct page *page;
> + 
> + 	if (WARN_ON(!workload->shadow_mm))
> + 		return;
> + 
> + 	if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
> + 		return;
> + 
> + 	page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
> + 	shadow_ring_context = kmap(page);
> + 	set_context_pdp_root_pointer(shadow_ring_context,
> + 			(void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
> + 	kunmap(page);
> + }
> + 
>   static int populate_shadow_context(struct intel_vgpu_workload *workload)
>   {
>   	struct intel_vgpu *vgpu = workload->vgpu;

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped