Alex Deucher [Fri, 19 Feb 2010 21:07:02 +0000 (16:07 -0500)]
drm/radeon/rv740: fix backend setup
This patch fixes occlusion queries and rendering errors
on rv740 boards. Hardcoding the backend map is not an optimal
solution, but a better fix is being worked on.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 18 Feb 2010 05:58:36 +0000 (15:58 +1000)]
[rfc] drm/radeon/kms: pm debugging check for vbl.
This patch adds a check on avivo chips to see if we are in the VBL
region for the active crtcs when we trigger the engine change.
I appear to have glitches locally on pm transistion (not sure all
fixes are in yet) and this at least seems to be correct here,
maybe others can test on systems with no glitches.
Pauli Nieminen [Mon, 1 Feb 2010 17:11:16 +0000 (19:11 +0200)]
drm/radeon: Fix memory allocation failures in the preKMS command stream checking.
Allocation of single large block of memory may fail under memory
presure. drm_buffer object can hold one large block of data in
multiple independ pages which preents alloation failures.
This patch converts all access to command stream to use drm_buffer
interface. All direct access to array has to go tough drm_buffer
functions to get correct pointer.
Outputting the command stream to ring buffer needs to be awear of
the split nature of drm_buffer. The output operation requires the
new OUT_RING_DRM_BUFFER.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Pauli Nieminen [Mon, 1 Feb 2010 17:11:15 +0000 (19:11 +0200)]
drm: Add generic multipart buffer.
Allocating multiple pages of memory for data that is coming
from user space may fail. To fix memory allocation failures
the buffer object should be split to multiple independ pages.
drm buffer provides generic interface to copy and process
large data arrays from user space.
Interface includes allocation and free functions to allocate
the buffer object and data storage pages.
All access operations are performed relative to a internal
pointer which is advanced with drm_buffer_advance function.
The buffer can be accessed using drm_buffer_pointer_to_XXX
functions if it is known that requested object doesn't split
over a page boundary. These functions don't do any error
checking to maximize performance.
If there is large object which could be split there is special
drm_buffer_read_object function. drm_buffer_read_object takes
a pointer as argument which is used as temporary store for
data if it is split over boundary in the buffer.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Get rid of _location and use _start/_end also simplify the
computation of vram_start|end & gtt_start|end. For R1XX-R2XX
we place VRAM at the same address of PCI aperture, those GPU
shouldn't have much memory and seems to behave better when
setup that way. For R3XX and newer we place VRAM at 0. For
R6XX-R7XX AGP we place VRAM before or after AGP aperture this
might limit to limit the VRAM size but it's very unlikely.
For IGP we don't change the VRAM placement.
Tested on (compiz,quake3,suspend/resume):
PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710
AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730
IGP:RS480(RPB*),RS690,RS780(RPB*),RS880
RPB: resume previously broken
V2 correct commit message to reflect more accurately the bug
and move VRAM placement to 0 for most of the GPU to avoid
limiting VRAM.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Tue, 16 Feb 2010 16:28:36 +0000 (11:28 -0500)]
drm/radeon/r600: fix warnings in CS checker
drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_cs_track_check’:
drivers/gpu/drm/radeon/r600_cs.c:166: warning: ‘bpe’ may be used uninitialized in this function
drivers/gpu/drm/radeon/r600_cs.c:166: note: ‘bpe’ was declared here
drivers/gpu/drm/radeon/r600_cs.c: In function ‘r600_cs_parse’:
drivers/gpu/drm/radeon/r600_cs.c:938: warning: ‘bpe’ may be used uninitialized in this function
drivers/gpu/drm/radeon/r600_cs.c:938: note: ‘bpe’ was declared here
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Mon, 15 Feb 2010 20:36:33 +0000 (21:36 +0100)]
drm/radeon/kms: fix bo's fence association
Previous code did associate fence to bo before the fence was emited
and it also didn't lock protected access to ttm sync_obj member.
Both of this flaw leads to possible race between different code
path. This patch fix this by associating fence only once the fence
is emitted and properly lock protect access to sync_obj member of
ttm.
Fix:
https://bugs.freedesktop.org/show_bug.cgi?id=26438
and likely similar others bugs Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Mon, 15 Feb 2010 20:36:13 +0000 (21:36 +0100)]
drm/radeon/kms: fix indirect buffer management V2
There is 3 different distinct states for an indirect buffer (IB) :
1- free with no fence
2- free with a fence
3- non free (fence doesn't matter)
Previous code mixed case 2 & 3 in a single one leading to possible
catastrophique failure. This patch rework the handling and properly
separate each case. So when you get ib we set the ib as non free and
fence status doesn't matter. Fence become active (ie has a meaning
for the ib code) once the ib is scheduled or free. This patch also
get rid of the alloc bitmap as it was overkill, we know go through
IB pool list like in a ring buffer as the oldest IB is the first
one the will be free.
Fix :
https://bugs.freedesktop.org/show_bug.cgi?id=26438
and likely other bugs.
Jerome Glisse [Thu, 11 Feb 2010 11:44:32 +0000 (12:44 +0100)]
drm/radeon/kms: fix r600/r700 cs checker to avoid double kfree
radeon_cs kfree the tracker structure but for r6xx/r7xx we want
to kfree it inside the parse function because we share it with
the UMS code path. Set tracker to NULL after freeing it will
avoid double free.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 5 Feb 2010 06:00:07 +0000 (16:00 +1000)]
drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page
this uses a new entrypoint to invalidate gart entries instead of using 0.
Changed to rather than pointing to 0 address point empty entry to dummy
page. This might help to avoid hard lockup if for some wrong
reasons GPU try to access unmapped GART entry.
I'm not 100% sure this is going to work, we probably need to allocate
a dummy page and point all the GTT entries at it similiar to what AGP does.
but we can test this first I suppose.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Michel Dänzer [Wed, 10 Feb 2010 10:05:11 +0000 (11:05 +0100)]
drm/radeon/kms: Test rdev->bios centrally in combios_get_table_offset().
It's happened time and time again (most recently with the support for EDID
hardcoded in the BIOS ROM) that new code didn't check for rdev->bios being
non-NULL before triggering dereferences of it. This would result in an
oops/panic on setups with no BIOS ROM. Hopefully this central test will be
more robust.
Signed-off-by: Michel Dänzer <daenzer@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Wed, 10 Feb 2010 22:30:05 +0000 (22:30 +0000)]
drm/radeon/kms: r600/r700 command stream checker
This patch add cs checker to r600/r700 hw. Command stream checking
will rewrite some of the cs value in order to restrict GPU access
to BO size. This doesn't break old userspace but just enforce safe
value. It should break any things that was using the r600/r700 cs
ioctl to do forbidden things (malicious software), though we are
not aware of such things.
Here is the list of thing we check :
- enforcing resource size
- enforcing color buffer slice tile max, will restrict cb access
- enforcing db buffer slice tile max, will restrict db access
We don't check for shader bigger than the BO in which they are
supposed to be, such use would lead to GPU lockup and is harmless
from security POV, as far as we can tell (note that even checking
for this wouldn't prevent someone to write bogus shader that lead
to lockup).
This patch has received as much testing as humanly possible with
old userspace to check that it didn't break such configuration.
However not all the applications out there were tested, thus it
might broke some odd, rare applications.
[airlied: fix rules for cs checker for parallel builds]
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Thu, 28 Jan 2010 17:22:31 +0000 (18:22 +0100)]
drm/radeon/kms: bogus cs recorder utilities
This add an utilities function radeon_ib_bogus_add which will
save an ib into a list of ib which can then be dumped using
debugfs. Once dumped the ib is removed from the list. This
should allow to save & capute ib for further debugging.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Fri, 5 Feb 2010 05:55:32 +0000 (00:55 -0500)]
drm/radeon/kms: dynclks fixes
- only r4xx/r5xx/rs6xx/rs740 have clock gating atom table,
so disable it on r6xx. it's already disabled on r7xx
- check to make sure the clock_gating hook exists before
calling it. This avoids a segfault on asics without
that function.
- remove unused static power management function.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Wed, 23 Dec 2009 18:21:58 +0000 (13:21 -0500)]
drm/radeon/kms: add a power state type based on power state flags
The idea is to flag a power state with a certain type and use
that type to decide on what state to select. On r6xx+, we
select a state and then transition between clock modes in that
state. On pre-r6xx, we transition between states directly.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Mon, 28 Dec 2009 18:58:44 +0000 (13:58 -0500)]
drm/radeon/kms: pull power mode info from bios tables (v3)
The general idea is to validate the current hw state
against the set of power states and select a power
state based on that. This patch just pulls the power
states from the bios and prints the information. It
is not currently hooked up in the actual power management
code. Hooking it up will require reworking the the current
power state selection code and will be handled in a future
patch.
Additionally, we'd need to decide on some default lower
power states for cards without power tables.
v2 - increment state_index after checking for default state
v3 - fix typo in pm init on pre-atom cards, handle pre-atom
cards without x86 bioses
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
V2: reorganize functions, fix modesetting calls
V3: rebase patch, use radeon's workqueue
V4: enable on tested chipsets only, request VBLANK IRQs
V5: enable PM on older hardware (IRQs, mode_fixup, dpms)
V6: use separate dynpm module parameter
V7: drop RADEON_ prefix, set minimum mode for dpms off
V8: update legacy encoder call, fix order in rs600 IRQ
V9: update compute_clocks call in legacy, not only DPMS_OFF
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Thu, 4 Feb 2010 16:01:52 +0000 (11:01 -0500)]
drm/radeon/kms/r600: reduce gpu cache flushing
Only flush the gpu caches before we submit a fence.
This leads to a small performance boost when we take
the extra gpu cache flushes out of the ddx and mesa.
Once this patch is in and the drm version is bumped,
we can remove the flushes from the ddx and drm.
Also, remove the extra cache flushes from the blit
routine.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Tue, 2 Feb 2010 17:06:28 +0000 (12:06 -0500)]
drm/radeon/kms: add pll quirk for toshiba laptop panel
The panel on the Toshiba A300-1BU laptop does not like the
PLL dividers selected by the avivo pll algo, but works fine
using the older method. Add a quirk to handle it.
Should fix fdo bug 26358.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Alex Deucher [Tue, 2 Feb 2010 17:05:01 +0000 (12:05 -0500)]
drm/radeon/kms: rework pll algo selection
Rework the pll algo selection so that the pll algo
in use can be selected more easily. This allows
us to select different pll divider selection algos
for specific monitors that work better with one algo
or the other. This is needed for the next patch which
adds an LVDS pll quirk for a specific notebook.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Fri, 5 Feb 2010 08:34:16 +0000 (03:34 -0500)]
drm/radeon/kms: add workaround for rn50/rv100 servers
Some servers have two VGA ports but only report
one in the bios connector tables. On these systems
always set up the TV DAC so that it displays properly
even if the bios is wrong.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Wed, 23 Dec 2009 08:23:21 +0000 (03:23 -0500)]
drm/radeon/kms: add support for hw i2c on r1xx-r5xx
wire hw i2c support into radeon i2c algo.
fixes merged:
- handle bus probing correctly
- use meaningful error numbers
- abort if transaction fails
- The line mapping is different depending on the asic.
- protect hw i2c engine with a mutex
- rs300 doesn't have a pin select bit
- r200 has a different pin select setup
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 5 Feb 2010 03:41:54 +0000 (13:41 +1000)]
drm/radeon/kms: rs400/480 MC setup is different than r300.
Boot testing on my rs480 laptop found the MC idle never happened
on startup, a quick check with AMD found the idle bit is in a different
place on the rs4xx than r300.
Implement a new rs400 mc idle function to fix this.
Jerome Glisse [Tue, 2 Feb 2010 10:51:45 +0000 (11:51 +0100)]
drm/radeon/kms: don't call suspend path before cleaning up GPU
In suspend path we unmap the GART table while in cleaning up
path we will unbind buffer and thus try to write to unmapped
GART leading to oops. In order to avoid this we don't call the
suspend path in cleanup path. Cleanup path is clever enough
to desactive GPU like the suspend path is doing, thus this was
redondant.
Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE)
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/gpu/drm/radeon/radeon_combios.c: In function 'radeon_combios_get_lvds_info':
drivers/gpu/drm/radeon/radeon_combios.c:893: warning: comparison is always false due to limited range of data type
Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
Randy Dunlap [Tue, 2 Feb 2010 22:40:33 +0000 (14:40 -0800)]
ati_pcigart: fix printk format warning
Fix ati_pcigart printk format warning:
drivers/gpu/drm/ati_pcigart.c:115: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Thu, 4 Feb 2010 19:36:39 +0000 (20:36 +0100)]
drm/radeon/kms: fix regression rendering issue on R6XX/R7XX
It seems that some R6XX/R7XX silently ignore HDP flush when
programmed through ring, this patch addback an ioctl callback
to allow R6XX/R7XX hw to perform such flush through MMIO in
order to fix a regression. For more details see:
http://bugzilla.kernel.org/show_bug.cgi?id=15186
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Thu, 4 Feb 2010 16:27:27 +0000 (17:27 +0100)]
drm/radeon/kms: move blit initialization after we disabled VGA
VGA might be overwritting VRAM and corrupt our blit shader leading
to corruption, it likely won't happen if you load fbcon right after
radeon. Thanks to Shawn Starr and Andre Maasikas for tracking down
this issue.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Michel Dänzer [Fri, 22 Jan 2010 08:20:00 +0000 (09:20 +0100)]
drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
If radeon_cs_parser_init() fails, radeon_cs_ioctl() calls
radeon_cs_parser_fini() with the non-zero error value. The latter dereferenced
parser->ib which hasn't been initialized yet -> boom. Add a test for parser->ib
being non-NULL before dereferencing it.
Signed-off-by: Michel Dänzer <daenzer@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 1 Feb 2010 01:35:47 +0000 (11:35 +1000)]
drm/radeon/kms: move radeon KMS on/off switch out of staging.
We are happy enough that the KMS driver is stable enough for enough people
for the kms enable/disable to leave staging. Distros can now contemplate
turning this on.
Jerome Glisse [Fri, 22 Jan 2010 14:19:00 +0000 (15:19 +0100)]
drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3
If an error happen in r600_blit_prepare_copy report it rather
than WARNING and keeping execution. For instance if ib allocation
failed we did just warn about but then latter tried to access
NULL ib ptr causing oops. This patch also protect r600_copy_blit
with a mutex as otherwise one process might overwrite blit temporary
data with new one possibly leading to GPU lockup.
Should partialy or totaly fix:
https://bugzilla.redhat.com/show_bug.cgi?id=553279
V2 failing blit initialization is not fatal, fallback to memcpy when
this happen
V3 init blit before startup as we pin in startup, remove duplicate
code (this one was actualy tested unlike V2)
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Peter Hanzel [Sat, 30 Jan 2010 03:38:07 +0000 (03:38 +0000)]
drm/vmwgfx: Request SVGA version 2 and bail if not found
This fixes the driver not loading on older versions of VMware.
Signed-off-by: Peter Hanzel <hanzelpeter@gmail.com> Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Richard Kennedy [Tue, 26 Jan 2010 17:10:48 +0000 (17:10 +0000)]
drm/ttm: remove padding from ttm_ref_object on 64bit builds
Re-order structure ttm_ref_object to remove 8 bytes of alignment padding
on 64 bit builds, so shrinking its size from 72 to 64 bytes allowing it
to fit into a smaller slab.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
John Kacur [Sun, 31 Jan 2010 19:38:03 +0000 (20:38 +0100)]
drm/kms/radeon/agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info
First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.
Signed-off-by: John Kacur <jkacur@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.
This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.
V2: fix silly addition of connector dig_block and cleanup the other
places in the code that pick the encoder.
V3: rename to dig_encoder and clean up further - also fix
the picking algorithm.
uses DRM_MODE_DPMS_ON for FB_BLANK_NORMAL, but DRM_MODE_DPMS_ON
is actually for turning output on instead of blank.
This makes fb blank broken on my T61, it put LVDS on but leave
pipe disabled which made screen totally white or caused some
'burning' effect.
[airlied: James objects to this but at this point in 2.6.33,
I can't see a patch that will fix this properly like he wants coming
in time and otherwise this is a regression - proper fix for 2.6.34
hopefully.]
Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 25 Jan 2010 03:08:08 +0000 (13:08 +1000)]
drm/radeon/kms: make hibernate work on IGPs
This is the least invasive fix without migrating the radeon driver
to pm_ops from what I can see. We just always migrate VRAM objects
on IGPs for now and we can fix it up later to migrate depending
on STR vs STD.
Dave Airlie [Mon, 25 Jan 2010 06:04:11 +0000 (16:04 +1000)]
Merge remote branch 'nouveau/for-airlied' of ../drm-nouveau-next into drm-linus
* 'nouveau/for-airlied' of ../drm-nouveau-next:
drm/nv50: prevent switching off SOR when in use for DVI-over-DP
drm/nv50: fail auxch transaction if reply count not what we expect
drm/nouveau: fix failure path if userspace specifies no valid memtypes
drm/nouveau: report LVDS as disconnected if lid closed
drm/nv50: prevent accidently turning off encoders we're actually using
drm/nv50: fix alignment of per-channel fifo cache
drm/nouveau: Evict buffers in VRAM before freeing sgdma
drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts
drm/nouveau: fix thinko in nv04_instmem.c
drm/nouveau: fix a race condition in nouveau_dma_wait()
Ben Skeggs [Thu, 21 Jan 2010 05:03:23 +0000 (15:03 +1000)]
drm/nouveau: fix failure path if userspace specifies no valid memtypes
We need to add the buffer to the list even if we fail, otherwise the
validate_fini() call won't unreserve + unreference the GEM object,
making TTM very unhappy.
Alex Deucher [Thu, 21 Jan 2010 22:14:49 +0000 (17:14 -0500)]
drm/radeon/kms/atom: atom parser fixes
Only reset the reg block on the initial execute
table call; nested calls require the reg block not be
reset on each call. Also reset the fb window and
io mode. This matches the upstream parser behavior.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Jerome Glisse [Mon, 18 Jan 2010 12:01:36 +0000 (13:01 +0100)]
drm/radeon: r6xx/r7xx possible security issue, system ram access
This patch workaround a possible security issue which can allow
user to abuse drm on r6xx/r7xx hw to access any system ram memory.
This patch doesn't break userspace, it detect "valid" old use of
CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte
the address these registers are pointing to with the one of the
last color buffer. This workaround will work for old mesa &
xf86-video-ati and any old user which did use similar register
programming pattern as those (we expect that there is no others
user of those ioctl except possibly a malicious one). This patch
add a warning if it detects such usage, warning encourage people
to update their mesa & xf86-video-ati. New userspace will submit
proper relocation.
Fix for xf86-video-ati / mesa (this kernel patch is enough to
prevent abuse, fix for userspace are to set proper cs stream and
avoid kernel warning) :
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b
http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f
Abusing this register to perform system ram memory is not easy,
here is outline on how it could be achieve. First attacker must
have access to the drm device and be able to submit command stream
throught cs ioctl. Then attacker must build a proper command stream
for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to
overwrite the GPU GART which is in VRAM. To achieve so attacker
as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point
to the GPU GART, then it has to find a way to write predictable
value into those buffer (with little cleverness i believe this
can be done but this is an hard task). Once attacker have such
program it can overwritte GPU GART to program GPU gart to point
anywhere in system memory. It then can reusse same method as he
used to reprogram GART to overwritte the system ram through the
GART mapping. In the process the attacker has to be carefull to
not overwritte any sensitive area of the GART table, like ring
or IB gart entry as it will more then likely lead to GPU lockup.
Bottom line is that i think it's very hard to use this flaw
to get system ram access but in theory one can achieve so.
Side note: I am not aware of anyone ever using the GPU as an
attack vector, nevertheless we take great care in the opensource
driver to try to detect and forbid malicious use of GPU. I don't
think the closed source driver are as cautious as we are.
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>