Hi !
> > It just polls the accelIdle bit and waits for it to come up while the ioctl
> > is still running.
> Alternatively, some cards can also send an interrupt when the accel
> engine has finished, no ? (But you need to protect the critical
> section whatsoever.)
Yes, though this doesn't help with the problem that was asked about.
For cards that lock up if someone accesses the fb while an accel command
is running, it is of no use to free the CPU for that time, as another process
might access the FB, thus locking up the system, which is pretty much what
we do not want.
For "behaved" cards, this is a good idea, though.
> > On SMP machines, you will have to put an explicit lock there. This needs
> > some support in the kernel. The IMHO best implementation would be to
> > unmap the framebuffer for _all_ processes while an accel is running.
> >
> > However this has a serious performance impact. Another possibility would be
> > to influence the scheduler to make sure only one process that accesses
> > /dev/gfx would run during this operation.
> Why not use a kernel lock here then? IMHO there should exist already
> some way to control this: setting up a mutex (0/1 semaphore) or lock
> associated to the framebuffer. HW accelerated operations would acquire
> the lock (on behalf of the hw engine that surely cannot do it itself)
> and release it when it is idle (this can be done via interrupt notification).
> Normal MMIO operations should also acquire this lock IMO. (Maybe this
> is where there is a potential problem? There is no way to set up
> semaphore control for shared-MMIO areas?)
The problem is, that on cards that lock up, we cannot rely on applications
acquiring this lock. An mmaping/unmapping the framebuffer is the only way to
ensure that an application can/cannot access the framebuffer.
I.e. the lock you propose will anyway have to be coupled to the mmaping/
unmapping of the framebuffer. Either by the lock inducing an unmap, as I
proposed above, or the other way round by the lock being set/reset at
map/unmap time.
The latter solution has the disadvantage, that you would have to mmap/unmap
very often, if you do not want to lock out acceleration, which is very
expensive.
> Isn't this possible? [We are in the usual case of mutual exclusion
> so, I'm turning towards conventional mechanism - but I don't know if
> they are really applicable.]
The point is, that we need to enforce the lock. If you do conventional
concurrent programming, your program will mess itself up, if it doesn't lock
properly. Your problem.
Now for the case in question, your program would mess up the whole system
(i.e. it would effectively allow for a serious denial of service attack),
if it doesn't lock properly. Everyone's problem ...
Thus we need to enforce the lock. And there are only two ways for that (if I haven't
missed one):
1. disallow access to the fb by using the memory remapping system of the
host processor.
2. disallow access to the fb by using the scheduling system to deny programs
that use the fb to run.
NOte, that all this only applies to cards that lock up.
Cards that just mess up display can be handled by conventional locking.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
