On 2010-06-10 at 08:29:56 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > > On 2010-06-09 at 14:12:33 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> > > > wrote: > > > Apart from the earliest 64 bit machines, all of the current ones > > > should > > > have a dedicated MMU for PCI devices. > > That would be helpful indeed. Haven't spotted it in the specs yet, > > though. > > Maybe this brings something to light (it seems to be machine > dependent): http://en.wikipedia.org/wiki/IOMMU Thanks. I finally found the specification [1]. > > > If that isn't available, and the > > > pages used lie outside the 4 GB range, a bounce buffer has to be > > > used. > > > Our DMAResource implementation should be able to deliver this all > > > one > > > day, but it will have to be used by all drivers that need its > > > functionality. > > ATM I don't see how you intend to extend DMAResource that it can be > > used > > for e.g. audio and network drivers. Those seem to mostly allocate > > contiguous RAM and write its physical address into some hardware > > register(s), which might only be 32 bit wide. The only thing that I > > can > > imagine to help (besides the dedicated MMU) is to somehow make sure > > that no > > memory beyond the 4 GB limit is allocated. > > Drivers that only use their own buffers (which most network drivers we > have do), would indeed only need buffers below that limit. Since this > is a TODO item in dma_resources.cpp, too, maybe we could just have a > create_area_etc() that takes a dma_restrictions as argument? Yep, something like that could be done -- though dma_restrictions contain stuff that is irrelevant for area creation. I've already extended vm_page_allocate_page_run() by an upper limit parameter. Alignment and boundary should be fairly simple to add, too. That would already cover all the page allocation backend must be able to do. CU, Ingo [1] http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf