Re: Address spaces on a i386 - Getting Confused (fwd)

Stephen C. Tweedie (sct@redhat.com)
Thu, 1 Apr 1999 01:21:13 +0100 (BST)


Hi,

On Wed, 31 Mar 1999 13:52:08 +0200, Jamie Lokier
<lkd@tantalophile.demon.co.uk> said:

>> But a solution to DMA'ing to user-space will be ...

>> c) Then trap into the kernel using an ioctl to set up kernel address
>> for this range. ( I bet there must be some VM calls to acheive that
>> ). What i mean is that get the pages behind the locked user-address
>> behind the kernel address.

> You make it sound so simple. Unfortunately it isn't.

> c) as you describe not possible:

That's odd, because I already have it working. :)

> In the kernel, a "kernel address" that can be DMA'd using the
> documented method (virt_to_bus) is in the direct mapped region. On
> i386, that's the region from 0xc0000000 up.

No problem. Finding the physical address of a kernel virtual address is
easy, and in fact we don't usually even need to do that, since
interrogating the page tables to find the user page's address in memory
gives us a true physical address directly. Finding the bus address of a
kernel physical address is easy.

> The device driver must be written to divide its DMA requirements into
> regions that don't cross non-contiguous page boundaries.

For block device IO, that's just fine: we either split up the IO or
submit it as a single block using scatter-gather DMA.

> It must look up the physical address from user-space (an architecture
> specific thing for which there is no reliable macro yet).

There are perfectly standard ways of doing this inside the kernel: the
macros to walk over page tables are already architecture-independent.

> As a future problem, some user-space pages will not be reachable by
> DMA anyway, because they are outside the bus address range of the
> device doing DMA. (cf. 32-bit PCI cards on >4GB memory machines, or
> complexities of multi-bus machines).

Indeed, and this is one of the problems I'll have to deal with for the
large memory support. IO bounce buffers will be necessary, but that
will be entirely transparent above the block device request layer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/