From owner-freebsd-hackers Fri Dec 7 9:21:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp-out.fr.alcove.com (ns1.alcove-solutions.com [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 69A4037B416 for ; Fri, 7 Dec 2001 09:21:32 -0800 (PST) Received: from cedar.alcove-fr ([10.16.10.12]) by smtp-out.fr.alcove.com with esmtp (Exim 3.12 #1 (Debian)) id 16COgg-0004eM-00; Fri, 07 Dec 2001 18:21:26 +0100 Received: from nsouch by cedar.alcove-fr with local (Exim 3.12 #1 (Debian)) id 16COgg-0004tq-00; Fri, 07 Dec 2001 18:21:26 +0100 Date: Fri, 7 Dec 2001 18:21:26 +0100 From: Nicolas Souchu To: Terry Lambert Cc: freebsd-hackers@freebsd.org, KGI Devel Subject: Re: kld VM pager Message-ID: <20011207182125.J17798@cedar.alcove-fr> References: <20011206143022.H13566@cedar.alcove-fr> <3C0F85FA.ED7F5BED@mindspring.com> <20011206164253.J13566@cedar.alcove-fr> <3C0F9B0D.4640D043@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C0F9B0D.4640D043@mindspring.com> User-Agent: Mutt/1.3.20i Organization: =?iso-8859-1?Q?Alc=F4ve?= =?iso-8859-1?Q?=2C?= http://www.alcove.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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