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.
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.
Jos� Fonseca
