On Wed, 1 May 2002, José Fonseca wrote: > Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in > own words: > > "Most of the first cut of the DMA code. It's got most of the > dispatch > architecture in place (Lacks actual DMA submission (The easy part, > really...)) > so it's not done yet, but I promised people that done or not, I'd do a > check-in > of this..." > > The part which is missing is more or less what we have in the > mach64-0-0-4-branch, except that the state update is still being made with > MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we > bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor > of the later, since it will avoid redundant work of merging back and > forward, and will also enable the PowerPC architecture to participate in > testing.
I agree. Frank is using basically the same setup for the descriptor table as I have, so that should merge well. We can add the necessary list initialization to _dma_init and keep the bus master test and setup from the mach64-0-0-4-branch, I think. One thing I realized concerning blits: the utah driver uses the host_data[0-15] registers to do blits which treats blits as a GUI-master operation. This means it works with pseudo-DMA. I think the better way to do it is to use the system bus master method and interrupt handling that Frank has set up. However, if we want to keep an MMIO mode, we'll have to have an alternate method for blits. > So before we starting the merge, it's needed to include the state update > in the buffers. Although I still have some concerns about security, the > fact is that the only security problem we've seen so far is that a > malicious client can lock the card (by setting a 0 texture address offset) > and is not clear that we can recover from that too. The DMA submission > does create some obstacules indiscriminate register access, as Frank > commented in his code: > > "Through some pretty thorough testing, it has been found that the > RagePRO engine will pretty much ignore any "commands" sent via the > gui-master pathway that aren't gui operations (the register gets set, but > the actions that are normally associated with the setting of those said > registers doesn't happen.). So, it's safe to send us buffers of gui > commands from userspace (altering the buffer in mid-execution will at > worst scribble all over the screen and pushing bogus commands will have no > apparent effect...)" > > But above all, is much easier to put the state update in the client for > now - while the security isn't completely worked out - so that we can move > forward with the DMA support, and at any time if we do come to the > conclusion that this model isn't secure we can easily switch back. This would make the driver work more like the utah setup, so it might make it easier to reuse some of the code, and it would be easier to get the proper order of state and vertex data in the buffers. On the security issue, I think we need to be careful about how we handle blits. Frank's code for _dma_buffers allows sending buffers to the DRM, does that mean this takes the place of _dma_vertex? I assume you still need to call this to allocate the buffers before filling them. -- Leif Delgass http://www.retinalburn.net
