Date: Thu, 06 Dec 2001 06:51:38 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nicolas Souchu <nsouch@fr.alcove.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kld VM pager Message-ID: <3C0F85FA.ED7F5BED@mindspring.com> References: <20011206143022.H13566@cedar.alcove-fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Nicolas Souchu wrote: > > Hi VM developers, > > Has anyone already some useful utils to develop a VM pager for FreeBSD? > The KGI port project is progressing and is now up to the point that I have > to handle the VM events as done in Linux. > > http://www.freebsd.org/~nsouch/ggiport.html Your "README.kgi" referenced by this page does not exist. I went looking for "graphic.c", and found it at: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kgi/kgi-0.9/kgi/Linux/linux/drivers/kgi/graphic.c>; From my reading of the code, all it is is a pseudo device that permits you to establish/remove memory mappings for various regions of the graphics card memory, which may or may not be apertured, into process address space, as a file buffer mapping. In FreeBSD, the VM and buffer cache are unified, so what you really want it to map the memory into the process space directly, rather than into the file (in Linux, this amounts to equating a region of a pseudo-file buffer cache to the memory on board the graphics card). Probably, you should look at the FreeBSD code for support of the mmap() of console video memory, which is part of the console driver itself, rather than looking at the mmap() code in the VM system for help. Worst case, you can look at the hook in for anonymous memory mappings in the /dev/zero pseudo device, but since it grabs anonymous pages, rather than explicit physical pages, it's much less interesting. The only issue I see that might be tough is that the aperture might be too small for the full card memory. If this is the case, you will probably need to allocate kernel memory for it, and do explicit coherency calls, after moving the aperture (if necessary). I don't think anything does this in FreeBSD now, so there might be read/write fault handler work required (e.g. unmap the memory, but reserve a mapping hole for it, and then move the aperture as necesswary to satisfy the fault, and restart the request; this assumes that the aperture is 4k or some multiple thereof, so it's on even page boundaries). I don't know of any video card where this would be required, but you could imagine one (e.g. the TI 99/4A had apertured 4k window onto video RAM, making it hard to update). I suspect you could just ignore the problem entirely (I don't see a fault handler for an aperture adjustment in the Linux code, but perhaps I'm not reading it correctly, or my memory of the Linux VM is not as fresh as it needs to be to correctly answer the question). > Reading the 4.4BSD Internals, I've understood that I should look in the pager > direction and the code shows that the device pager is not much far from my > willing... Actually, it's very far away. Unfortunately, the book you are looking at doesn't know about the VM and buffer cache unification which occurred in FreeBSD, so it doesn't know that the memory in the buffer cache _IS_ the backing object, as far as you are concerned. Since you don't care about backing store, there isn't an explicit coherency requirement (even in Linux, there is no such explicit coherency requirement, since you are operating on the mmap'ed object directly... which is why Linux doesn't require a backing store allocation, either). > More precisely, has anybody some way to load/unload a pager? Is it really > possible? What advices could you address me before I start this? You really don't want to do this. Just map the memory directly into the target process address space (see examples, cited above). If the issue is mapping it into the kernel virtual address space, a cheap way of doing both is to set the PG_U bit on the page, which will make the kernel memory space visible to (all) user processes. This might lack sufficient priviledge protection for your tastes. The alternative is to map it into both address spaces. Matt Dillon could give you more help, as could Bruce Evans, Alfred Perlstein, me, or half a dozen other people, when you decide the effect you are trying to achive, rather than trying to do exactly what Linux does to achieve the effect, assuming that the examples aren't sufficient by themselves. Let one of us know; I'm personally very intersted in seeing this get into FreeBSD, considering 386BSD first started working on something like this back at the end of 1992. -- Terry 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?3C0F85FA.ED7F5BED>