Date: Wed, 4 Mar 2009 09:13:10 +1000 (EST) From: Peter Grehan <grehan@freebsd.org> To: Justin Hibbits <jrh29@alumni.cwru.edu>, freebsd-ppc@freebsd.org Subject: Re: graphics on G4 Message-ID: <20090304091310.EQW86822@dommail.onthenet.com.au>
next in thread | raw e-mail | index | archive | help
Hi Justin, >>What happens if we have physical or device memory in the >>same range as kmem VAs? This shouldn't happen: kmem VAs use seg regs 13 and 14 i.e. the virtually-mapped space is 0xD000.0000 -> 0xEFFF.FFFF. Kernel physical memory is 1:1 mapped, using BAT registers, as is i/o space. Since there are only 4 BAT registers used, a DSI trap will evict a BAT and re-use it, if the faulting address falls in the battable[] array. See powerpc/aim/trap_subr.s:dsitrap(). Now, mapping the frame buffer from user-space *doesn't* use the BATs, but instead uses PTEs from user VA. Each process has unique segment register values which prevent it from corrupting memory in other address spaces (including the kernel's). >> > > >It seems like trying to modify it through the BAT map (as >> > > >zero/copy page, /dev/mem and friends do) will overwrite >> > > >random bits of KVA instead... Shouldn't do, since KVA doesn't occupy that space. >I wrote a simple kernel module to print out BAT and segment registers, and the >output immediately following boot is: >Later, and I don't know precisely what is meant by "later", registers 540 and 541 get changed to 0x4......., which >means the video memory gets un-BAT-mapped. That is probably a BAT spill, which should be harmless. None of the above helps, I know :( But it's outlining what should be happening. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090304091310.EQW86822>