Re: [Dri-devel] MACH64_BM_GUI_TABLE(_CMD)?

[Leif D. <lde...@re...>]

On Fri, 3 May 2002, Jos=E9 Fonseca wrote:

> As I was studying the specs and code to be able to understand and reply=
 to=20
> Leif's previous post (which I haven't completed yet..), I noticed at th=
e=20
> same time a bug and a feature which could mean that blind client buffer=
ing=20
> could be insecure after all.
>=20
> The bug is that we should be using MACH64_BM_GUI_TABLE and not=20
> MACH64_BM_GUI_TABLE_CMD when setting up the GUI master operation. The=20
> difference between the two is that the later is queued in the FIFO and =
the=20
> former not, and we really don't want this as it could get in the way la=
ter.

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,=20
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=20
> GUI master operation, as said in the BM_DATA register spec (8-11).=20

This can't be right since the setup engine registers are in block 1 and w=
e=20
are using them in a GUI master op.  That's what BUS_EXT_REG_EN @ BUS_CNTL=
=20
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 maste=
r
> 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=
=20
> for concern since the commands are only innocent(?) GUI operations, thi=
s=20
> gives the ability of setting up any descriptor table. One consequence i=
s=20
> that if this table is invalid the whole DMA engine is unnoperational un=
til=20
> 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=20
as well.

btw, I also noticed that HOST_CNTL has a bit for big-endian translation o=
f
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=20
Peter's texture problem.

> I plan to build a test case for this, but I would like to hear prelimin=
ary=20
> opinions about this, in case I'm missing something. Frank, have you tes=
ted=20
> this before?

Yeah, the first thing is to determine if it's really possible to kick off=
=20
a second DMA pass from within a DMA buffer.

--=20
Leif Delgass=20
http://www.retinalburn.net