From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: Use Graphics Base of Stolen Memory on all gen3+ Date: Thu, 4 Jul 2013 11:55:57 +0200 Message-ID: <20130704095557.GY18285@phenom.ffwll.local> References: <1372893813-15817-1-git-send-email-chris@chris-wilson.co.uk> <20130703233335.GI19383@cantiga.alporthouse.com> <20130703235508.GJ19383@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20130703235508.GJ19383@cantiga.alporthouse.com> Sender: stable-owner@vger.kernel.org To: Chris Wilson , Daniel Vetter , intel-gfx , stable List-Id: intel-gfx@lists.freedesktop.org On Thu, Jul 04, 2013 at 12:55:08AM +0100, Chris Wilson wrote: > On Thu, Jul 04, 2013 at 01:38:05AM +0200, Daniel Vetter wrote: > > On Thu, Jul 4, 2013 at 1:33 AM, Chris Wilson wrote: > > > On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote: > > >> On Thu, Jul 4, 2013 at 1:23 AM, Chris Wilson wrote: > > >> > So I made the mistake of missing that the desktop and mobile chipsets > > >> > have different layouts in their PCI configurations, and we were > > >> > incorrectly setting the wrong physical address for stolen memory on > > >> > mobile chipsets. > > >> > > > >> > Since all gen3+ are actually consistent in the location of the GBSM > > >> > register in the PCI configuration space on device 2 (the GPU), use it. > > >> > > > >> > Signed-off-by: Chris Wilson > > >> > Cc: Daniel Vetter > > >> > Cc: stable@vger.kernel.org > > >> > > >> Nope, not cc: stable since the last time around the overlay blew up in > > >> flames ... > > > > > > You can comment out gen3, but the dangerous part is that we are > > > overwriting random physical addresses. > > > > Hm, should we do a request_region on the stolen range to double-check > > that? Just for paranoia and in case the BIOS does something terrible > > ... > > Afaict, request_region() is only being used to reserve and check for > conflicting io ranges. I don't know if that will give us protection > against overwriting user/kernel memory. Maybe it does - I haven't found > the documentation for it yet. On a quick reading (I didn't really try it out in practice) the e820 code inserts resource nodes for each memory segment into the resource tree. So I think this should indeed work out. At least request_mem_region seems to check for IORESOURCE_BUSY and e820_reserve_resources seems to set that on all memory regions managed by the kernel (if I read the magic checks correctly). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch