Date: Thu, 6 Dec 2001 16:42:54 +0100 From: Nicolas Souchu <nsouch@fr.alcove.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org, KGI Devel <kgi-develop@lists.sourceforge.net> Subject: Re: kld VM pager Message-ID: <20011206164253.J13566@cedar.alcove-fr> In-Reply-To: <3C0F85FA.ED7F5BED@mindspring.com> References: <20011206143022.H13566@cedar.alcove-fr> <3C0F85FA.ED7F5BED@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Dec 06, 2001 at 06:51:38AM -0800, Terry Lambert wrote: > 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. True, until I fix it, I join it to the mail. > 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. Although I'm not completly aware of KGI VM features, it seems to be a bit more complex (I quote entirely your mail and cc to KGI mailing for this reason). As you consider it later, the VM is supposed to move the aperture window if the hardware does not support linear frame buffering (VGA 64k window for example). This is a minimal feature for the so-called mmio resources. Some other kind of resources may be mapped as well, especially acceleration resources like DMA, graphic pipelines... to provide the user application a uniform API (memory mapping) for any kind of hw capacities. > 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. In this case, the mmap() is made on the /dev/console, no? Which is a file entry like /dev/graphic would be. > 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 Isn't the pager responsible for this? > 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. But, I don't want any kind of buffering. /dev/graphic is just a Unix-like file entrypoint to pass orders to the VM. > 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). What would handle my VM faults in this case? > 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 I'd accept help with pleasure. > effect you are trying to achive, rather than trying to do exactly I'm not sure of the expected effect, this is why the KGI project is in copy. > 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. You're speaking about this kind of VM handling or KGI? > -- Terry Thanks Terry. -- Alcôve Technical Manager - Nicolas.Souchu@fr.alcove.com - http://www.alcove.com FreeBSD Developer - nsouch@freebsd.org --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="README.kgi" // README // This document is intended to present the FreeBSD KGI design. It has been written while developing the FreeBSD KGI port in order to give some hints about the architecture. It's certainly not complete but should provide enough knowledge for a kernel developer to understand what's going in general. Code is there for the rest ;) Linux and FreeBSD kernels are different by *many* ways, but KGI has been especially designed to hide this complexity and provide driver developers a uniform API independent of the platform. One caveat is that KGI interfaces were initially written to hide *Linux* particular way of thinking. Consequently, abstraction is just in line with Linux's way of life. For example, even if some KGI functions provide OS independent PCI scanning capacities, they make the assumption that the device driver is responsible for such operations. In FreeBSD the PCI core implementation is responsible for parsing the PCI bus and drivers, throw a unique probe() and attach() scheme. Drivers are only supposed to validate if they correspond to the PCI device when they're triggered by the PCI core. The newbus architecture provides a generic framework for programming device drivers indepently of the underlying hardware layout. It offers a bus abstraction to link device drivers in a object oriented manner where device drivers are parent/child of each others. This scheme offers powerful features like resource inheritance (mmio, irqs) really useful for a graphical board implementation. But, one of KGI goal is to provide an interface *independent* of the platform (architecture and OS). Then, there's no way to take advantage of FreeBSD powerful features if we want (and we must) keep this compatibility. KGI drivers are really modular. The code for the clock, ramdac and chipset is seperated in 3 link objects that may be linked later according to the board hardware layout. Each of these objects is separated in two C files -bind.c and -meta.c which are respectively implement the OS dependent and OS independent parts of the drivers (clock, ramdac, chipset are considered as drivers). So, one could think: cool, just rewrite -bind.c for FreeBSD and you win! That's not so cool/easy. -bind.c contains a lot of code which is by definition also mostly independent of the Un*x implementation you consider. So, there's no reason not to take advantage of it. Later maybe one could imagine some improvment in this area and a rewrite -bind.c to take advantage of advanced OS kernel features. So, how's going with FreeBSD? Is a board device driver a parent of clock, ramdac and chipset drivers? Certainly. IMHO, the board manages the resources of the graphic card and distributes them to each components. The chipset has a particular role since it interfaces the board to the bus (AGP, PCI...) so it manages most PCI resources. The chipset is also the unique way for identifying the board on the bus. Additionnal bios and registers can then be used to distinguish boards from one to another. In FreeBSD implementation, the board entity is a full FreeBSD device driver, respecting the newbus interfaces, connected to the PCI core and responsible for dispatching the resources to the KGI underlying clock, ramdac and chipset drivers (as they exist in the Linux implementation). The board driver probe/attach routines detect the chipset, prepare the kgi display information and call the kgim functions to powerup the KGI drivers. clock ramdac chipset \ | / \ | / - board - ... PCI (third dimension) | KGI / \ / \ event graphic When the board module is loaded into the FreeBSD kernel, the probe routine has already acknowledged the chipset existance. Consequently, during the attach call, when the KGI chipset driver is powered up, the pci_find() routine is a nop instruction. Later, resource reservation like irq_claim and check_region are converted into FreeBSD bus_resource() calls. // EOF // --ADZbWkCsHQ7r3kzd-- 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?20011206164253.J13566>