On Sunday 20 March 2005 17:23, Nicolai Haehnle wrote: > On Friday 18 March 2005 15:48, Lourens Veen wrote: > > On Friday 18 March 2005 10:48, Nicolai Haehnle wrote: > > > So we will have to deal with mmap()ing video memory in normal userspace > > > programs. > > > > How does this work? I mean, from a programmer point of view, you mmap() a > > buffer and everything you write into it ends up in the mapped piece of > > memory, in this case card memory. But it has to be transfered somehow. > > Does > > > every write cause a kernel trap that sends the bytes over the bus to the > > card? That sounds awfully slow. > > 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? > > The reason I'm asking is that I'm wondering whether it would be feasible > > to > > > add a few gates on the card that replace values with 0 (in case of > > reading, > > > good for patching the "read secret information from another window" hole) > > and/or block writes, based on the value in the ownership buffer. > > 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. Lourens _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
