Date: Fri, 7 Dec 2001 18:21:26 +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: <20011207182125.J17798@cedar.alcove-fr> In-Reply-To: <3C0F9B0D.4640D043@mindspring.com> References: <20011206143022.H13566@cedar.alcove-fr> <3C0F85FA.ED7F5BED@mindspring.com> <20011206164253.J13566@cedar.alcove-fr> <3C0F9B0D.4640D043@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 06, 2001 at 08:21:33AM -0800, Terry Lambert wrote: > Nicolas Souchu wrote: [...] > If only a part of the card memory is visible in physical memory, Yes. > 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. That was my first guess. > > > 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. This makes the difference. > Specifically, grep arounf for "d_mmap". Yep. In case of the VGA, the VGA d_mmap is only responsible for giving the device pager the physical address for a given offset in the mapped region. We don't want the VGA d_mmap to do the HW aperture update, the dev_pager_getpages() should do it instead. > 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. In case of the device pager, the dev_pager_putpages() is never called. > 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. As explained by Rodolphe, mmappings may also be used to map other kind of resources which are not 100% memory by design. [...] > > > 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. Yep. > > 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. ;^). Yes, fortunatly I'm not alone on this project. Nicholas -- Alcôve Technical Manager - Nicolas.Souchu@fr.alcove.com - http://www.alcove.com FreeBSD Developer - nsouch@freebsd.org 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?20011207182125.J17798>