Date: Thu, 6 Dec 2001 13:13:55 -0500 (EST) From: "Brian S. Julin" <bri@tull.umassp.edu> To: Nicolas Souchu <nsouch@fr.alcove.com> Cc: freebsd-hackers@freebsd.org, KGI Devel <kgi-develop@lists.sourceforge.net> Subject: Re: kld VM pager Message-ID: <Pine.LNX.4.21.0112061231110.8477-100000@tull.umassp.edu> In-Reply-To: <20011206164253.J13566@cedar.alcove-fr>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll take a shot at qualifying what is is that KGI wants: Yes, we definitely want page-fault handlers if we can possibly get them: 1) For fossil cards where the aperture is smaller than the VRAM, with impossible-or-dangerous-to-expose-to-userpace aperture control. Also this provides naive applications with often desired contiguous direct buffer access. 2) For fossil planar mode cards with dangerous-to-expose-to-userspace plane-mask controls, to allow for direct access to different planes/plane-masks such that naive applications need not explicitly use an IOCTL to set the plane masks. * 3) For resources of lower access privilage which are move around inside an aperture of higher privilage (e.g. if an area of VRAM controlled by a normal application must be relocated in VRAM by a session leader.) 4) For policing access to RAM, usually DMA-capable RAM, such that the application can write accelerator commands to a page and submit the page to the kernel, which then revokes write privilages until the page has been proofread and swapped for a clean page such that it can be executed asyncronously, while the application obliviously continues to write commands. Page faults and blocking behavior are needed in this case in order to provide a ring-buffer-like feel to applications that use the ring-buffer paradigm for command FIFOs, and doubtless they will become useful in implementing a display-list paradigm as well. In a perfect world, a user application would be able to explicitly say where it wants pages mapped (and which command-queue pages are ready for execution) by altering some shared memory that serves as a control interface to the VM, and as long as the application's request is sane, the requested mapping would occur on the next page fault on the existing mapping, explicitly through IOCTL, or asyncronously as desired (obviously we need to work on advisory locking for the VM control/status interface.) The items listed above could all use such a mechanism to acheive secure access, but in addition to that, the sugar of emulated ring buffers and emulated contiguous apertures using page faults are minor technical enhancements that are major API improvements, as they ease porting applications that were coded to graphics systems that had those features. Under Linux a few mods to speed up the VM are needed, as we can demand that the userpace application not attempt anything esoteric under penality of death by the kernel and thus remove some cruft, but basically other than that we can define our own VM fault handler that remaps things as we please... what's the story under FreeBSD? * Why support such cretinous hardware? Laptops. Especially of the non-x86 variety. -- Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0112061231110.8477-100000>