Date: Thu, 06 Dec 2001 08:21:33 -0800 From: Terry Lambert <tlambert2@mindspring.com> 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: <3C0F9B0D.4640D043@mindspring.com> References: <20011206143022.H13566@cedar.alcove-fr> <3C0F85FA.ED7F5BED@mindspring.com> <20011206164253.J13566@cedar.alcove-fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Nicolas Souchu wrote: > > 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. [ ... ] > 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. If the intent is just to turn non-linear into linear from the perspective of an applicaiton, and the boundary is always 4K or more, and it's not an access aperture that needs the card to be sent a control message to expose a different region in the host visible window, then you just need to make a bunch of different mappings to make non-linear physical memory into linear virtual memory. I'm not sure if I understand you, though. Is all of the card memory visible in physical memory, or is only part of the card memory visible in physical memory? Forget virtual for a second. If only a part of the card memory is visible in physical memory, then you will have to do fault handling, as I first suggested. FreeBSD doesn't support external pagers, per se. You might be able to hook it in, but really, it's not expected. You really want to look at /sys/vm/device_pager.c. > > 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. No. The console is handled by the device pager. It is a special device, not a file. Device nodes are handled differently. Specifically, grep arounf for "d_mmap". The main problem, if there is really an aperture you have to move around, is that there's an implicit asumption that you have all the memory mapped, and the "put" is as simple as just writing to memory, so you aren't going to get the write fault that gets handled by a fault handler that you need. You might be able to hack together something based on the code in /sys/vm/swap_pager.c, but you would need to do the same as swap_pager_unswapped() on the pages in the prior aperture, if you adjusted the aperture at all. I find it incredibly hard to believe that anyone would build a video card that would be so slow to access, but I could easily be wrong here. > > 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? Not really. The card is still backing store, but it has different physical memory exposed. It's more like a disk driver, at that point, where the physical disk is acting as backing store for RAM (except you want the write through to be immediate, not deleayed, as it would be with a disk driver, so that your changes are reflected when you want them to be, instead of some time later). Basically you "address" the card memory into the window and write it, the same way you do PIO to a disk, where the host is responsible for the DMA into the disk RAM that represents the addressed sector. It's possible to write a different pager to do this, but you would have to really work to hook it in. Basically, you would open the device, and work up the chain and replace it in the vnode that was opened for the device. The problem with doing this is that you are then responsible for instance reference counting, and you have to ask for close notifications to be able to do this (they are[were?] not default). > > 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. You have buffering, anyway, if you have an aperture mapping that is changing. Minimally, you have to take a fault on the write to any memory not currently exposed in the aperture, remap the aperture, and then restart the operation with the fault having been satisfied. So you will need to remap the pages as having or not having "backing store" in the form of memory within the aperture window. > > > 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? It would have to be your code, remapping the aperture. Do video cards like this really exist? > > 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. I think you will need to understand what the code wants before you ask for help. ;^). > > 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? KGI. -- 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?3C0F9B0D.4640D043>