linux-kernel - drm/cirrus: Ignore busy mem region when mapping VRAM

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-next>] [day] [month] [year] [list]

Message-ID: <52EB804C.2090506@canonical.com>
Date:	Fri, 31 Jan 2014 10:51:56 +0000
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	David Herrmann <dh.herrmann@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Dave Airlie <airlied@...hat.com>,
	Stefan Bader <stefan.bader@...onical.com>
Subject: drm/cirrus: Ignore busy mem region when mapping VRAM

I know this is a gross hack but something like that currently is required to
avoid a KVM guest booted from graphical grub mode (so simplefb is taking effect)
getting into a state where there is no framebuffer in use at all (since simplefb
was removed but cirrus fails to acquire VRAM resources which are held by the
platform device). _Guests in that stage appear to be frozen but can be reached
via network login with no problems.

It would be possible to release the mem region in the simplefb driver when
unmapping but that sounds equally bad. Is someone already looking into some
better solution here? Should the platform device be removed or what would be a
good way to go forward here?

-Stefan

--

From 5eaa87a69bb40ffeec759b6e5aeec1a26bba1680 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@...onical.com>
Date: Wed, 29 Jan 2014 16:45:12 +0000
Subject: [PATCH] drm/cirrus: Ignore busy mem region when mapping VRAM

Since 29d274b8d3e2404cd1832b3a999b12f9d1e1d895 ("x86/simplefb: Mark
framebuffer mem-resources as IORESOURCE_BUSY to avoid bootup warning")
the messages for real hw drivers mapping the same region as the simple-
framebuffer are gone. But now the cirrus drm driver will always fail
to initialize its VRAM because the region is busy. Removing the
conflicting framebuffer only can stop simplefb from using the memory
and unmap it but it is the platform device which has the region assined
to itself.
As the comment of the above patch indicates there is currently no sane
way to get rid of the platform device. So at least for now accept that
the region can appear busy. It is usuable nonetheless.
This will fix VMs using the cirrus gfx emulation to appear locked up
when booting from GRUB gfx mode.

BugLink: http://bugs.launchpad.net/bugs/1269401

Signed-off-by: Stefan Bader <stefan.bader@...onical.com>
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 557d094..9f0193f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -101,8 +101,15 @@ static int cirrus_vram_init(struct cirrus_device *cdev)

 	if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
 				"cirrusdrmfb_vram")) {
-		DRM_ERROR("can't reserve VRAM\n");
-		return -ENXIO;
+		/*
+		 * With the simple-framebuffer now marking the region
+		 * busy there is no way of this succeeding with having
+		 * the framebuffer active. Getting here means the old
+		 * one has been kicked and the region is unmapped but
+		 * there is no way to eject the platform device to get
+		 * the request_region undone.
+		 */
+		DRM_ERROR("can't reserve VRAM (ignored)\n");
 	}

 	return 0;
-- 
1.8.3.2

View attachment "0001-drm-cirrus-Ignore-busy-mem-region-when.patch" of type "text/x-diff" (2086 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)