Patch "drm/vmwgfx: Work around mode set failure in 2D VMs" has been added to the 4.4-stable tree

[<gregkh@linuxfoundation.org>]

This is a note to let you know that I've just added the patch titled

    drm/vmwgfx: Work around mode set failure in 2D VMs

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-vmwgfx-work-around-mode-set-failure-in-2d-vms.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From 7c20d213dd3cd6295bf9162730e7a368af957854 Mon Sep 17 00:00:00 2001
From: Sinclair Yeh <syeh@vmware.com>
Date: Wed, 29 Jun 2016 11:29:47 -0700
Subject: drm/vmwgfx: Work around mode set failure in 2D VMs

From: Sinclair Yeh <syeh@vmware.com>

commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream.

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.

Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |    7 +++++++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |    9 +--------
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -703,6 +703,13 @@ static int vmw_driver_load(struct drm_de
 			vmw_read(dev_priv,
 				 SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB);
 
+		/*
+		 * Workaround for low memory 2D VMs to compensate for the
+		 * allocation taken by fbdev
+		 */
+		if (!(dev_priv->capabilities & SVGA_CAP_3D))
+			mem_size *= 2;
+
 		dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE;
 		dev_priv->prim_bb_mem =
 			vmw_read(dev_priv,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1538,14 +1538,7 @@ int vmw_du_connector_fill_modes(struct d
 		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
 	};
 	int i;
-	u32 assumed_bpp = 2;
-
-	/*
-	 * If using screen objects, then assume 32-bpp because that's what the
-	 * SVGA device is assuming
-	 */
-	if (dev_priv->active_display_unit == vmw_du_screen_object)
-		assumed_bpp = 4;
+	u32 assumed_bpp = 4;
 
 	if (dev_priv->assume_16bpp)
 		assumed_bpp = 2;


Patches currently in stable-queue which might be from syeh@vmware.com are

queue-4.4/drm-ttm-make-ttm_bo_mem_compat-available.patch
queue-4.4/drm-vmwgfx-delay-pinning-fbdev-framebuffer-until-after-mode-set.patch
queue-4.4/drm-vmwgfx-add-an-option-to-change-assumed-fb-bpp.patch
queue-4.4/drm-vmwgfx-check-pin-count-before-attempting-to-move-a-buffer.patch
queue-4.4/drm-vmwgfx-work-around-mode-set-failure-in-2d-vms.patch
queue-4.4/drm-vmwgfx-fix-error-paths-when-mapping-framebuffer.patch