Aliasing physical memory using virtual memory (from a driver's perspective)

[Stevie-O <oliver@klozoff.com>]

I'm working on a driver for a PCI card that outputs a LOT of data.  Think tens 
of megabytes per second.

Each separate DMA transfer is for about 640KB of data. Since the standard PC 
architecture was designed too cheaply to have a set of DMA remapping registers, 
it's highly unlikely that even in That Other OS will one find 160 consecutive 
free pages.  Thus, the card has a built-in scatter-gather mechanism.

The driver needs to do some processing on each 640KB chunk before passing it 
onto userspace (there are reasons why this processing can't happen in userspace, 
that's all anyone should need to know).  There's a sort-of-a-shortcut that is 
currently done that processes 9 pages worth at once.  Since the 9 pages need to 
be contiguous, the driver (sadly) kmalloc()s the scatter-gather buffer in 9-page 
chunks; if I understand the slab stuff correctly, this actually winds up 
allocating 16 *consecutive* pages for each sub-buffer.   16 consecutive pages is 
  still kinda hard to come by, however, so the driver allocates a very large 
pile at startup.

The card uses physical memory, but if I understand things correctly (which I 
probably don't), the driver/kernel runs on virtual memory.

My thinking is this: I want to use __get_free_pages(1) 80 times to get the 160 
pages, then passed those 80 pieces to the card (it's known the card can handle 
requests with that many pieces).  Then I want to create a *virtually* contiguous
160-page mapping, so the postprocessing code in the driver can view the 80 
2-page sub-buffers as one big consecutive 160-page buffer.  Doing this would (a) 
make for more efficient use of memory, and (b) leave the larger piles of 
contiguous pages to the drivers of cards that actually require them.

Is this possible?

-- 
- Stevie-O

Real Programmers use COPY CON PROGRAM.EXE