R300 idling (new subject)

[Vladimir Dergachev]

On Sat, 18 Dec 2004, Adam Jackson wrote:

> On Saturday 18 December 2004 03:27, Vladimir Dergachev wrote:
>>>>>> do things is to do a proper cache flush (plus whatever magic is
>>>>>> required) each time 3d activity is followed by 2d one.
>>>>>
>>>>> So is emitting the cache flush(es) in EnterServer() not enough?
>>>>
>>>> No. A user-space client is perfectly entitled to  mix 2d and 3d code
>>>> and a proper DRM driver must be able to prevent lockups in case
>>>> user-space client screws up.
>>>
>>> We've never guaranteed "prevent lockups in case user-space client screws
>>> up" before.  Generally reducing lockups in that case is nice, I'd say,
>>> but the "must" would be a new requirement.
>>
>> Oh..  This would mean we gave up on security, I hope it is not true..
>
> Our security model is, if you have access to /dev/dri/card? and the X server
> let you connect, then you can write directly to the hardware.  There are
> plenty of other DoS attacks you can perform once you have a connection to the
> server.

I thought that we only let the Mesa driver access "safe" registers and the 
rest was done through DRM driver. I understand that many drivers access 
video memory directly, but my impression was that this was a compromise to 
deliver a working driver earlier and/or for suboptimal hardware.

>
> Don't like it?  Help me figure out accelerated indirect rendering, which would
> let you restrict drm device access to root (the server) and still get
> accelerated 3d.

This might be fun :) What are the current issues ? Is there a place I can 
read about them ?

                         best

                           Vladimir Dergachev

>
> - ajax
>