RE: Address spaces on a i386 - Getting Confused

Paul Sargent (Paul.Sargent@3dlabs.com)
Tue, 30 Mar 1999 13:12:25 +0100


Ahhhh, so the kernel is always stored at physical address 0x00000000
onwards, which is constantly mapped in at 0xC0000000 onwards. Therefore you
can get the physical address by lopping of the 0xC, but only on kernel
addresses.

Makes sense.

So presumably the other option is to allocate kernel memory and then pass a
pointer to it back to user space. Is that possible?

Paul

> -----Original Message-----
> From: David Miller [SMTP:davem@twiddle.net]
> Sent: Tuesday, March 30, 1999 12:44 PM
> To: Paul.Sargent@3dlabs.com
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Address spaces on a i386 - Getting Confused
>
> From: Paul Sargent <Paul.Sargent@3dlabs.com>
> Date: Tue, 30 Mar 1999 12:29:31 +0100
>
> But I'm still confused by the virt-to-phys macro. I would have
> thought if I want to find the physical address of a user space
> buffer I would have to go through the page table to fins out where
> is physical page is, not just mask off some bits.
>
> It cannot be used on user space buffers, this is what you are missing.
>
> Sounds like you want to point the DMA controller of some device at
> user space pages, the closest mechanism that exists for doing this is
> in the drivers/video/bttv.c video capture card driver, but it's a
> kludge.
>
> The problem is that you have to keep track of all of the nasties when
> you want to do something special with user pages, you'd have to:
>
> 1) Increment the reference count to the page_struct of that physical
> page.
>
> 2) Mark the user TLB mappings read-only so the user cannot write to
> the pages while the device is fiddling with it.
>
> 3) Undo all of this when the card is done and wake up the user if he
> went to sleep because he wanted to write to the page (and thus
> took a page fault because we mapped it read-only to ensure
> exclusive access for the device)
>
> You also have to deal with the cases where the page is mapped by
> multiple processes, etc. it's a can of worms.
>
> Later,
> David S. Miller
> davem@redhat.com

-
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/