Messages in this thread | | | Date | Sun, 4 Apr 1999 20:56:59 +0200 | From | Jamie Lokier <> | Subject | Re: 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/
| |