On Sunday 20 March 2005 18:07, Lourens Veen wrote: > > You directly map physical memory that corresponds to the card's entry in > > the PCI bus. Depending on whether the mapping is cacheable or not (this is > > an MTRR setting) writes first go into the CPU cache and are later flushed > > onto the bus, or they directly cause transactions on the bus. > > The kernel doesn't get involved in any of this (except for the setup phase, > > obviously), so it's just as fast as writing the data from the kernel - > > still a lot slower than RAM, but not absolutely crawling. > > Ah, so it's a feature of the memory controller to "forward" certain addresses > to the bus instead of to RAM, and that is controlled by the MTRR's. Correct?
I'm not really an expert in these things, but as far as I know, it's the northbridge which decides where memory accesses from the CPU go (this must be different in the latest Athlons), and the MTRR is internal to the CPU and only configures stuff like cache behaviour. > The card cannot know which process caused the PCI transaction to occur, so > > this is simply not possible. > > It can if the kernel tells it which process currently holds the DRI lock. > Whenever the lock is obtained, the kernel (via PIO or direct DMA) writes the > new value to the "current owner" register, ensuring that any write commands > are filtered according to who currently holds the lock. Since you can only > draw when you hold the lock, this would ensure that a process can never read > or write outside its window. Once the video memory has been mmapped, the userspace process can do with it whatever it wants, including accessing it while it doesn't have the hardware lock. So the only way to force it would be to unmap video memory whenever a process gives up the lock and fault it back in only if the process owns the lock. I don't know if there's any precedent for something like this in the kernel. Besides, you'd only want this for window security, and window security has deeper issues even if you don't mmap the video memory. cu, Nicolai
pgpiVJORNT9jV.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
