[Intel-gfx] [PATCH 5/8] drm/i915: Add the display switch logic for vgpu in i915 driver

[Wang, Zhi A]

Hi Chris:
    Thanks for the comment. See my comments below.

-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of Chris Wilson
Sent: Friday, September 19, 2014 4:15 PM
To: Song, Jike
Cc: Vetter, Daniel; intel-gfx at lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add the display switch logic for vgpu in i915 driver

On Sat, Sep 20, 2014 at 02:47:05AM +0800, Jike Song wrote:
> From: Yu Zhang <yu.c.zhang at intel.com>
> 
> Display switch logic is added to notify the vgt mediator that current 
> vgpu have a valid surface to show. It does so by writing the 
> display_ready field in PV INFO page, and then will be handled in vgt 
> mediator. This is useful to avoid trickiness when the VM's framebuffer 
> is being accessed in the middle of VM modesetting, e.g. compositing 
> the framebuffer in the host side
> 
> Signed-off-by: Yu Zhang <yu.c.zhang at intel.com>
> Signed-off-by: Jike Song <jike.song at intel.com>
> Signed-off-by: Zhiyuan Lv <zhiyuan.lv at intel.com>
> ---
>  drivers/gpu/drm/i915/i915_dma.c      |  8 ++++++++
>  drivers/gpu/drm/i915/i915_reg.h      |  7 +++++++
>  drivers/gpu/drm/i915/intel_display.c | 10 ++++++++++
>  3 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> b/drivers/gpu/drm/i915/i915_dma.c index bb4ad52..d9462e1 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1790,6 +1790,14 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
>  	} else {
>  		/* Start out suspended in ums mode. */
>  		dev_priv->ums.mm_suspended = 1;
> +		if (intel_vgpu_active(dev)) {
> +			/*
> +			 * Notify a valid surface after modesetting,
> +			 * when running inside a VM.
> +			 */
> +			I915_WRITE(vgt_info_off(display_ready),
> +				VGT_DRV_DISPLAY_READY);

That's interesting. As i915.ko is definitely not ready at this point.

Zhi: Will remove this piece in V2, as we have already had a similar logic in intel_crtc_set_config.

> +		}
>  	}
>  
>  	i915_setup_sysfs(dev);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> b/drivers/gpu/drm/i915/i915_reg.h index a70f12e..38d606c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6673,5 +6673,12 @@ enum punit_power_well {  #define 
> vgt_info_off(x) \
>  	(VGT_PVINFO_PAGE + (long)&((struct vgt_if *) NULL)->x)
>  
> +/*
> + * The information set by the guest gfx driver, through the 
> +display_ready field  */ enum vgt_display_status {
> +	VGT_DRV_DISPLAY_NOT_READY = 0,
> +	VGT_DRV_DISPLAY_READY,	/* ready for display switch */
> +};
>  
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b78f00a..3af9259 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11642,6 +11642,16 @@ static int intel_crtc_set_config(struct drm_mode_set *set)
>  			intel_modeset_check_state(set->crtc->dev);
>  	}
>  
> +	if (intel_vgpu_active(dev)) {
> +		/*
> +		 * Notify a valid surface after modesetting,
> +		 * when running inside a VM.
> +		 */
> +		struct drm_i915_private *dev_priv = dev->dev_private;
> +
> +		I915_WRITE(vgt_info_off(display_ready), VGT_DRV_DISPLAY_READY);

Should there not be some coordination before we start the modeset?

Zhi: In the design of GVT-g, there will be only one VM can occupy the display monitor at one time,
which is called "Foreground VM". Switching foreground VM is implemented by switching only a part
of display registers e.g. DSPCNTR/DSPSURF/DISPSTRIDE/DSPLINOFF/DSPTILEOFF. Other display 
mode set registers are virtualized to VM. So we may not care about the beginning of a modeset
sequence here.

But we really expect to know when a VM can be switched to foreground, which is, VM has
already configured those registers to valid values. If we switch a VM without valid values in those
registers to foreground e.g. during VM booting time, I'm afraid that's not what we expect...

-Chris

--
Chris Wilson, Intel Open Source Technology Centre _______________________________________________
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx