On Fri, 3 May 2002, José Fonseca wrote: > As I was studying the specs and code to be able to understand and reply to > Leif's previous post (which I haven't completed yet..), I noticed at the > same time a bug and a feature which could mean that blind client buffering > could be insecure after all. > > The bug is that we should be using MACH64_BM_GUI_TABLE and not > MACH64_BM_GUI_TABLE_CMD when setting up the GUI master operation. The > difference between the two is that the later is queued in the FIFO and the > former not, and we really don't want this as it could get in the way later.
I think the reason for the alias is that the card increments the GUI_TABLE_ADDR @ BM_GUI_TABLE as it consumes descriptors, so writing to BM_GUI_TABLE could disrupt a DMA pass in progress. Using the alias ensures that the commands already in the FIFO/command buffers are processed before changing the table address. However, as you say below, it could potentially be used inside a command buffer as well. > Only commands which are on block 0 of MMIO region can be streamed into a > GUI master operation, as said in the BM_DATA register spec (8-11). This can't be right since the setup engine registers are in block 1 and we are using them in a GUI master op. That's what BUS_EXT_REG_EN @ BUS_CNTL is for. > The MACH64_BM_GUI_TABLE_CMD is an alias in this block exactly for this > purpose, i.e., to be streamed trhough the GUI command FIFO, as said in > its spec (8-12). Doesn't this means that we can initiate further GUI > master operations from a command buffer since, once the first GUI master > operation is setup, it's only necessary to set MACH64_BM_GUI_TABLE_CMD > and MACH64_DST_HEIGHT_WIDTH to fire it up - both accessible from GUI > FIFO. We definitely don't want clients changing the descriptor table head from inside a dma buffer. > Although firing up a stream of arbitrary commands shouldn't be a reason > for concern since the commands are only innocent(?) GUI operations, this > gives the ability of setting up any descriptor table. One consequence is > that if this table is invalid the whole DMA engine is unnoperational until > a cold reset. Another is that they can access to any register... If it's really possible to do this, you might be able to set up a blit as well. btw, I also noticed that HOST_CNTL has a bit for big-endian translation of host data. At 15 and 16bpp, it swaps bytes within each word and at 32bpp it reverses the order of the 4 bytes within each dword. This might fix Peter's texture problem. > I plan to build a test case for this, but I would like to hear preliminary > opinions about this, in case I'm missing something. Frank, have you tested > this before? Yeah, the first thing is to determine if it's really possible to kick off a second DMA pass from within a DMA buffer. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
