lkml.org 
[lkml]   [1999]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Address spaces on a i386 - Getting Confused (fwd)
Thanks Stephen, I understand, it is all so clear now!

Stephen C. Tweedie wrote:
> > /dev/ramdisk is another, that needn't be in the kernel address range.
>
> Block devices are not mmapable, so there is no issue here.

Files on block devices _are_ mmapable. Or they should be. One imagines
that files on /dev/ramdisk map the memory directly, but I could be
wrong. Isn't there a ROM variation on this that embedded systems use?

> Jamie, there are actually two sets of macros for doing phys/virt address
> translation on Intel. The __io_phys and __io_virt macros in
> asm-i386/io.h use bitops to convert between the addressp spaces, but in
> asm-i386/page.h, __va and __pa use only addition and subtraction. All
> the VM checks for page addresses use MAP_NR() and pte_page(), both of
> which are coded using __va/__pa, so we can never confuse a valid
> physical address with an IO region address in the PCI upper memory.

And on non-Intel? This fine distinction (bitops vs. arithmetic) does
not seem to be consistent across architectures.

> Me too. It gets worse: I really want to be able to do block device IO
> anywhere in the first 4G of physical memory. That suddenly requires
> that bh->b_data must support virt_to_phys() operations correctly for any
> physical memory. Ultimately that is something we can deal with, but it
> does complicate matters and reqquires us to live with temporary
> virt/phys mappings for IOs in progress.

Fortunately temporary mappings are required for the minority of IOs on
<1G machines.

And the mappings can be made very fast when required. We can avoid
flushing the TLB contexts by using a circular buffer of mappings, and
only flushing when we wrap around that buffer.

> Heck yes, every time. :) Ultimately if we can do the dynamic mapping
> issue right (and I've spoken to Linus about this, there _are_ ways we
> can deal with this) then dma to/from framebuffer becomes possible.

I was about to complain about the dynamic mapping overhead.
But then I though of the brilliant TLB-flush-avoiding strategy above :)

You haven't said how to get the _bus_ addresses for DMA though.
I haven't seen a portable phys_to_bus yet...

> vmalloc as a special case is one case which is completely out of the
> scope of this project: we _always_ have a physical address to start off
> with, as a that is what we get from the pte.

1. Sometimes an address passed to a system call does not have an associated
pte. Dave Miller once pointed out that the Sparc port handles the
direct-mapped kernel area in the TLB miss handler without tables.
Occasionally, a system call is called with such an address.

2. ioremap is what a framebuffer will use in general.
So our example has to support reverse-translation of ioremap ranges.

> Whether it was vmalloced
> or not in the first place, we always start this particular part of the
> problem with a canonical physical address and the only problem is how do
> we make sure that we can also deal with it as a virtual address which is
> what bh->b_data needs.

I agree that with a few ifs and elses, getting the physical address is
easy, for all addresses that a system call may be passed.

We may also assume that any device that is mmaped doesn't have to be
accessed through the readl/writel I/O macros.

> (For things like programmed IO, we *must* have a
> viable virtual address for the duration of the IO, but there's no need
> to have that virtual address persist after the IO.)

> > Me need sleep. Real bad :) Moving house later :)
>
> Good luck!

Ahh, nicely settled in now.
Time to solicit some visitors methinks.
Anyone in the St Genis-Pouilly area? :)

-- Jamie

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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.131 / U:1.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site