How to get the physical page addresses from a kernel virtual address for DMA SG List?

How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Clemens Koller]

Hello!

This might be an FAQ - I've got several ideas from googling
around for days and reading 'Linux Device Drivers' or
'Understanding The Linux Kernel' which are both really good
books. However I am not really sure of how to do it on the latest
linux-2.6.

I am currently working on a dma driver for a ppc32 system.
The idea is that a userspace app allocates a big contigous
chunk of memory (i.e. 400MBytes, user virtual mem) and tells
my dma's char driver via ioctl the pointer to that memory.

In the driver I can now use that (void __user *) casted address
as a kernel virtual address, right? It's contigous there and I can
do a memcpy() to get data to userspace simliar to a copy_to_user().
fine!

But I want to setup a scatter/gather DMA list and blow my data
directly into the applications physical pages.

What's the best way to setup the dma_sg_list?
I have checked several things to get the pages and physical addresses
but with no real success now:
get_user_page()
vmalloc_to_page()
kvirt_to_bus() (deprecated?)
virt_to_phys()
virt_to_bus()

Or do I need to remap the whole thing before I can get all the pages and
physical addresses?
remap_page_range()
remap_pfn_range()
map_user_kiobuf()
unmap_kiobuf()

Or do I need the direct-io stuff or the block-io?
How do I need to alloc the mem in my app? (get_pages()?)
How do I need to lock the memory to make sure it's in phys memory? (mlockall()?)
Can somebody please put some light on what's _the_ way to do that on the
latest 2.6 kernels? I am pretty much confused which functions are current
and okay to use to solve my problem.
Pointers to some code is also very welcome. But it should be _current_.
I've spent already a lot of time reading outdated things. :-(

Best regards,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[linux-os (Dick Johnson)]

You are trying to do it backwards. You need to have your driver
use get_dma_pages() to acquire pages suitable for DMA. Your
driver then impliments mmap().

The user-mode application then mmaps() the dma-able pages into
its address-space. FYI, the pages may be from anywhere, some
archs can only DMA to/from memory below 16MB. The pages do not have
to be continuous because you will build a scatter-list for
the DMA engine and you will mmap() the pages so they are
contiguous to the user. Also 400 Megabytes is absurd.

On Thu, 4 Aug 2005, Clemens Koller wrote:

> Hello!
>
> This might be an FAQ - I've got several ideas from googling
> around for days and reading 'Linux Device Drivers' or
> 'Understanding The Linux Kernel' which are both really good
> books. However I am not really sure of how to do it on the latest
> linux-2.6.
>
> I am currently working on a dma driver for a ppc32 system.
> The idea is that a userspace app allocates a big contigous
> chunk of memory (i.e. 400MBytes, user virtual mem) and tells
> my dma's char driver via ioctl the pointer to that memory.
>
> In the driver I can now use that (void __user *) casted address
> as a kernel virtual address, right? It's contigous there and I can
> do a memcpy() to get data to userspace simliar to a copy_to_user().
> fine!
>
> But I want to setup a scatter/gather DMA list and blow my data
> directly into the applications physical pages.
>
> What's the best way to setup the dma_sg_list?
> I have checked several things to get the pages and physical addresses
> but with no real success now:
> get_user_page()
> vmalloc_to_page()
> kvirt_to_bus() (deprecated?)
> virt_to_phys()
> virt_to_bus()
>
> Or do I need to remap the whole thing before I can get all the pages and
> physical addresses?
> remap_page_range()
> remap_pfn_range()
> map_user_kiobuf()
> unmap_kiobuf()
>
> Or do I need the direct-io stuff or the block-io?
> How do I need to alloc the mem in my app? (get_pages()?)
> How do I need to lock the memory to make sure it's in phys memory? (mlockall()?)
> Can somebody please put some light on what's _the_ way to do that on the
> latest 2.6 kernels? I am pretty much confused which functions are current
> and okay to use to solve my problem.
> Pointers to some code is also very welcome. But it should be _current_.
> I've spent already a lot of time reading outdated things. :-(
>
> Best regards,
>
> Clemens Koller
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Clemens Koller]

Hello, Dick!

Thanks for your help so far!

linux-os (Dick Johnson) wrote:
> 
> You are trying to do it backwards. You need to have your driver
> use get_dma_pages() to acquire pages suitable for DMA. Your
> driver then impliments mmap().

Okay, I have seen that, too. I've seen that some drivers do it the other
way around as I do, but I still try to follow my idea that the
application allocs the memory and the dma / the driver fills it up.
Or are there fundamental problems I get with my approach which I haven't seen yet?

> The user-mode application then mmaps() the dma-able pages into
> its address-space. FYI, the pages may be from anywhere, some
> archs can only DMA to/from memory below 16MB.

My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
space so, that's not an issue here.

> The pages do not have
> to be continuous because you will build a scatter-list for
> the DMA engine and you will mmap() the pages so they are
> contiguous to the user.

Yes, only virtual space is contigous. The DMA can do nice
sg_lists and chained sg_lists, so, this should not be a problem,
too.

> Also 400 Megabytes is absurd.

Why?
Actually I am planning to alloc more than 1.5GByte at once,
lock that down, build a big sg_list for all that memory because
I need to _continously_ feed it with data from the DMA. I get
about 200MBytes/sec and I cannot stop in between!

Greets,

Clemens



> On Thu, 4 Aug 2005, Clemens Koller wrote:
> 
> 
>>Hello!
>>
>>This might be an FAQ - I've got several ideas from googling
>>around for days and reading 'Linux Device Drivers' or
>>'Understanding The Linux Kernel' which are both really good
>>books. However I am not really sure of how to do it on the latest
>>linux-2.6.
>>
>>I am currently working on a dma driver for a ppc32 system.
>>The idea is that a userspace app allocates a big contigous
>>chunk of memory (i.e. 400MBytes, user virtual mem) and tells
>>my dma's char driver via ioctl the pointer to that memory.
>>
>>In the driver I can now use that (void __user *) casted address
>>as a kernel virtual address, right? It's contigous there and I can
>>do a memcpy() to get data to userspace simliar to a copy_to_user().
>>fine!
>>
>>But I want to setup a scatter/gather DMA list and blow my data
>>directly into the applications physical pages.
>>
>>What's the best way to setup the dma_sg_list?
>>I have checked several things to get the pages and physical addresses
>>but with no real success now:
>>get_user_page()
>>vmalloc_to_page()
>>kvirt_to_bus() (deprecated?)
>>virt_to_phys()
>>virt_to_bus()
>>
>>Or do I need to remap the whole thing before I can get all the pages and
>>physical addresses?
>>remap_page_range()
>>remap_pfn_range()
>>map_user_kiobuf()
>>unmap_kiobuf()
>>
>>Or do I need the direct-io stuff or the block-io?
>>How do I need to alloc the mem in my app? (get_pages()?)
>>How do I need to lock the memory to make sure it's in phys memory? (mlockall()?)
>>Can somebody please put some light on what's _the_ way to do that on the
>>latest 2.6 kernels? I am pretty much confused which functions are current
>>and okay to use to solve my problem.
>>Pointers to some code is also very welcome. But it should be _current_.
>>I've spent already a lot of time reading outdated things. :-(
>>
>>Best regards,
>>
>>Clemens Koller
>>_______________________________
>>R&D Imaging Devices
>>Anagramm GmbH
>>Rupert-Mayer-Str. 45/1
>>81379 Muenchen
>>Germany
>>
>>http://www.anagramm.de
>>Phone: +49-89-741518-50
>>Fax: +49-89-741518-19
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
> 
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> I apologize for the following. I tried to kill it with the above dot :
> 
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
> 
> Thank you.
> 

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Steven Rostedt]

On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
> > You are trying to do it backwards. You need to have your driver
> > use get_dma_pages() to acquire pages suitable for DMA. Your
> > driver then impliments mmap().
> 
> Okay, I have seen that, too. I've seen that some drivers do it the other
> way around as I do, but I still try to follow my idea that the
> application allocs the memory and the dma / the driver fills it up.
> Or are there fundamental problems I get with my approach which I haven't seen yet?

The driver doing the allocation would probably be easier.  Do you mean
that the application will do some large malloc and then pass that
address to the driver?  The driver would then need to map in those pages
since most of them would probably not be even allocated yet (no physical
memory associated to them).  Then there's always the point to prevent
abuse by the user.  If the driver did the allocation, it would just be
easier to control.

> 
> > The user-mode application then mmaps() the dma-able pages into
> > its address-space. FYI, the pages may be from anywhere, some
> > archs can only DMA to/from memory below 16MB.
> 
> My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
> space so, that's not an issue here.

I guess you don't mind that your driver will be locked to a specific
architecture. Or at least one that can handle these requirements. Is
this just for a single use?

> 
> > The pages do not have
> > to be continuous because you will build a scatter-list for
> > the DMA engine and you will mmap() the pages so they are
> > contiguous to the user.
> 
> Yes, only virtual space is contigous. The DMA can do nice
> sg_lists and chained sg_lists, so, this should not be a problem,
> too.
> 
> > Also 400 Megabytes is absurd.
> 
> Why?
> Actually I am planning to alloc more than 1.5GByte at once,
> lock that down, build a big sg_list for all that memory because
> I need to _continously_ feed it with data from the DMA. I get
> about 200MBytes/sec and I cannot stop in between!

Wow! what a system you must have :-)   With a 32 bit address space that
really does take a big chunck out of it.  Well I guess whatever device
this driver is for must be for some specific architecture.

-- Steve

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Arjan van de Ven]

On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
> Hello, Dick!
> 
> Thanks for your help so far!
> 
> linux-os (Dick Johnson) wrote:
> > 
> > You are trying to do it backwards. You need to have your driver
> > use get_dma_pages() to acquire pages suitable for DMA. Your
> > driver then impliments mmap().
> 
> Okay, I have seen that, too. I've seen that some drivers do it the other
> way around as I do, but I still try to follow my idea that the
> application allocs the memory and the dma / the driver fills it up.
> Or are there fundamental problems I get with my approach which I haven't seen yet?

there are some very funamental problems with that;
say the user allocation is only half the page, and he uses the other
half of the page for something else.
during the DMA some other thread calls fork().

Now the stuff under DMA can't COW of course, so only one half gets it.
But.. what to do with the second half of the page?

this is just one of the many fine fundamental issues you'll face ;)

Re: How to get the physical page addresses from a kernel virtualaddress for DMA SG List?

[linux-os (Dick Johnson)]

On Thu, 4 Aug 2005, Steven Rostedt wrote:

> On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
>>> You are trying to do it backwards. You need to have your driver
>>> use get_dma_pages() to acquire pages suitable for DMA. Your
>>> driver then impliments mmap().
>>
>> Okay, I have seen that, too. I've seen that some drivers do it the other
>> way around as I do, but I still try to follow my idea that the
>> application allocs the memory and the dma / the driver fills it up.
>> Or are there fundamental problems I get with my approach which I haven't seen yet?
>
> The driver doing the allocation would probably be easier.  Do you mean
> that the application will do some large malloc and then pass that
> address to the driver?  The driver would then need to map in those pages
> since most of them would probably not be even allocated yet (no physical
> memory associated to them).  Then there's always the point to prevent
> abuse by the user.  If the driver did the allocation, it would just be
> easier to control.
>
>>> The user-mode application then mmaps() the dma-able pages into
>>> its address-space. FYI, the pages may be from anywhere, some
>>> archs can only DMA to/from memory below 16MB.
>>
>> My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
>> space so, that's not an issue here.
>
> I guess you don't mind that your driver will be locked to a specific
> architecture. Or at least one that can handle these requirements. Is
> this just for a single use?
>
>>
>>> The pages do not have
>>> to be continuous because you will build a scatter-list for
>>> the DMA engine and you will mmap() the pages so they are
>>> contiguous to the user.
>>
>> Yes, only virtual space is contigous. The DMA can do nice
>> sg_lists and chained sg_lists, so, this should not be a problem,
>> too.
>>
>>> Also 400 Megabytes is absurd.
>>
>> Why?
>> Actually I am planning to alloc more than 1.5GByte at once,
>> lock that down, build a big sg_list for all that memory because
>> I need to _continously_ feed it with data from the DMA. I get
>> about 200MBytes/sec and I cannot stop in between!
>
> Wow! what a system you must have :-)   With a 32 bit address space that
> really does take a big chunck out of it.  Well I guess whatever device
> this driver is for must be for some specific architecture.
>
> -- Steve

The software architecture is simply wrong. He wants to DMA data
into user-space, continuously, faster than the CPU can do anything
with the data. If the data is anything more than an experiment
in "how fast can DMA write to RAM", then the data needs to be
used, i.e., processed. In the real world of high-speed data
processing (like image processing), one writes, using DMA or
whatever, into a buffer that is to be processed. DMA is often
used so that more data can be received while the previously-
received data is being processed. The buffers are usually
allocated as a linked-list or as a pair of buffers to be
ping/ponged. Allocating a gigantic buffer for any purpose,
including sorting databases, is simply wrong.

Data processing involves accessing data in arrays or
structures that emulate arrays of aggregate types. This
means that nearby elements are usually accessed, not elements
that are randomly scattered throughout address-space. This
locality of action is well known and is in fact why
paging is possible to provide virtual address-space.

Allocation of DMA pages by the user will fail. This is
because many of the user's pages will likely point to
the exact same page of (probably non-existant) RAM.
That's how a virtual memory system works. In fact,
allocation of virtual address space from user-mode
just tells the kernel not to seg-fault the user if
an access is made that hasn't been allocated yet.

When the access is made, a page-fault occurs and
the kernel tries to find some RAM to satisfy that access.
So, the physical addresses of any pages of allocated
RAM are not known until the pages are accessed. With
demand-zero paging, they all point to the same page
and won't change until an attempt to write to the
page occurs. After that, they may even change again.

Attempts to prevent that using mlockall() may simply
return -ENOMEM with such a large amount of virtual
address allocated. Getting the physical addresses
of user-mode virtual address RAM, involves searching
through page-tables to find out where the kernel
got a particular allocation from. This is because
every process has the exact same virtual address-space
but they share only the kernel and 'C' runtime
library address-space. All other virtual to physical
address-translations are different for different
processes.

This is why the driver must obtain the DMA pages and
the user must use mmap() to map those pages into its
address space. It's not a matter of being "easier",
it's a matter of it being the only way that will work.

Also, if Mr. Koller insists upon doing the absurd, i.e.,
allocating gigabytes of DMA RAM, he is going to have to
reserve memory that only his driver knows about, using
the "mem=" parameter on the boot command line. Then the
"extra" RAM above the kernel can be mapped using
ioremap_nocache() and made available for DMA and mmap().


Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: How to get the physical page addresses from a kernel virtualaddress for DMA SG List?

[Steven Rostedt]

On Thu, 2005-08-04 at 10:56 -0400, linux-os (Dick Johnson) wrote:
> On Thu, 4 Aug 2005, Steven Rostedt wrote:
> >
> > The driver doing the allocation would probably be easier.  Do you mean
> > that the application will do some large malloc and then pass that
> > address to the driver?  The driver would then need to map in those pages
> > since most of them would probably not be even allocated yet (no physical
> > memory associated to them).  Then there's always the point to prevent
> > abuse by the user.  If the driver did the allocation, it would just be
> > easier to control.
> >
[...]
> 
> The software architecture is simply wrong. He wants to DMA data
> into user-space, continuously, faster than the CPU can do anything
> with the data. If the data is anything more than an experiment
> in "how fast can DMA write to RAM", then the data needs to be
> used, i.e., processed. In the real world of high-speed data
> processing (like image processing), one writes, using DMA or
> whatever, into a buffer that is to be processed. DMA is often
> used so that more data can be received while the previously-
> received data is being processed. The buffers are usually
> allocated as a linked-list or as a pair of buffers to be
> ping/ponged. Allocating a gigantic buffer for any purpose,
> including sorting databases, is simply wrong.
> 

I just figured that his system was something unique and that he knows
what he's doing in regard to that.

> Data processing involves accessing data in arrays or
> structures that emulate arrays of aggregate types. This
> means that nearby elements are usually accessed, not elements
> that are randomly scattered throughout address-space. This
> locality of action is well known and is in fact why
> paging is possible to provide virtual address-space.
> 
> Allocation of DMA pages by the user will fail. This is
> because many of the user's pages will likely point to
> the exact same page of (probably non-existant) RAM.
> That's how a virtual memory system works. In fact,
> allocation of virtual address space from user-mode
> just tells the kernel not to seg-fault the user if
> an access is made that hasn't been allocated yet.

[snip long explaination of the VM layer]

> 
> This is why the driver must obtain the DMA pages and
> the user must use mmap() to map those pages into its
> address space. It's not a matter of being "easier",
> it's a matter of it being the only way that will work.

Well it definitely looks easier to me :-) I wouldn't say it's the only
way it will work, I would be kinder and say any other way would be
excruciatingly harder! As you explained.

> 
> Also, if Mr. Koller insists upon doing the absurd, i.e.,
> allocating gigabytes of DMA RAM, he is going to have to
> reserve memory that only his driver knows about, using
> the "mem=" parameter on the boot command line. Then the
> "extra" RAM above the kernel can be mapped using
> ioremap_nocache() and made available for DMA and mmap().
> 

Yeah the reserving of 1.5+G would be difficult in a 32 bit address
space. But I'm sure there's ways around it.

He never actually said what his goal was. This could be simply academic,
I don't know.  But if he got it to work, at least that would be cool.
(although I would never do such a thing in the "real" world ;-)


-- Steve

Re: How to get the physical page addresses from a kernel virtualaddress for DMA SG List?

[Clemens Koller]

Hello, colleagues!

Thanks again for your points!
I understand that we do the malloc the other way around and that this
might be wrong from your point of view. I also see that there are
issues with that, which I am about to carry into our software
development for discussion. Maybe we will change things there.

But the basic idea is still to use all amount of free physical ram for
dma'ing our data... for that it shouldn't matter who allocates it
(user or kernel). As long as I can get my physical address to it, which
was my problem.
It would be also nice to alloc that dynamically (not mem=, ioremap/mmap)
to allow the system to use the memory for other things, when
our application is not doing it's crazy job.

To give you some details about the application:
Our system and so the driver is specific to our hardware, which is
an embedded mpc8540 based highspeed framegrabber for 200MByte/sec.
All memory acces granularity is page oriented... so there are no
shared pages or other things like that. The memory gets alloced
by the app once, locked once, and re-used until the app exits.
There is no swapping or other tricky things.
The CPU's task is to process the data already while there is still
new data coming in. Processed data gets written to a RAID system
as fast as possible via another DMA engine.

Just for an example:
A frame of an image has about 40MBytes size.
The system is able to do multishot images as fast as possible until
the physical memory is full. If memory gets released as a processed frame
is written to disk, we can trigger another frame from the framegrabber
dma. etc. pp.
So, this system for sure is "special" - it's all about performance here.
And some hacks are okay as long as we know what we do (with your help).
It's not an academic thing... it's a product :-)

And, finally, I got the answer to my question of
how I can get the physical address of my virtual?:

-> the baby is called    iopa()

it takes a virtual address and gives me the physical address. :-)
It does this by walking through the page tables (which is afaik not
a trivial thing and maybe not portable, too).

It seems to work fine... and I can now blow data the way I want...
And yes, it is fast! B-)

Best greets,

Clemens


Steven Rostedt wrote:
> On Thu, 2005-08-04 at 10:56 -0400, linux-os (Dick Johnson) wrote:
> 
>>On Thu, 4 Aug 2005, Steven Rostedt wrote:
>>
>>>The driver doing the allocation would probably be easier.  Do you mean
>>>that the application will do some large malloc and then pass that
>>>address to the driver?  The driver would then need to map in those pages
>>>since most of them would probably not be even allocated yet (no physical
>>>memory associated to them).  Then there's always the point to prevent
>>>abuse by the user.  If the driver did the allocation, it would just be
>>>easier to control.
>>>
> 
> [...]
> 
>>The software architecture is simply wrong. He wants to DMA data
>>into user-space, continuously, faster than the CPU can do anything
>>with the data. If the data is anything more than an experiment
>>in "how fast can DMA write to RAM", then the data needs to be
>>used, i.e., processed. In the real world of high-speed data
>>processing (like image processing), one writes, using DMA or
>>whatever, into a buffer that is to be processed. DMA is often
>>used so that more data can be received while the previously-
>>received data is being processed. The buffers are usually
>>allocated as a linked-list or as a pair of buffers to be
>>ping/ponged. Allocating a gigantic buffer for any purpose,
>>including sorting databases, is simply wrong.
>>
> 
> 
> I just figured that his system was something unique and that he knows
> what he's doing in regard to that.
> 
> 
>>Data processing involves accessing data in arrays or
>>structures that emulate arrays of aggregate types. This
>>means that nearby elements are usually accessed, not elements
>>that are randomly scattered throughout address-space. This
>>locality of action is well known and is in fact why
>>paging is possible to provide virtual address-space.
>>
>>Allocation of DMA pages by the user will fail. This is
>>because many of the user's pages will likely point to
>>the exact same page of (probably non-existant) RAM.
>>That's how a virtual memory system works. In fact,
>>allocation of virtual address space from user-mode
>>just tells the kernel not to seg-fault the user if
>>an access is made that hasn't been allocated yet.
> 
> 
> [snip long explaination of the VM layer]
> 
> 
>>This is why the driver must obtain the DMA pages and
>>the user must use mmap() to map those pages into its
>>address space. It's not a matter of being "easier",
>>it's a matter of it being the only way that will work.
> 
> 
> Well it definitely looks easier to me :-) I wouldn't say it's the only
> way it will work, I would be kinder and say any other way would be
> excruciatingly harder! As you explained.
> 
> 
>>Also, if Mr. Koller insists upon doing the absurd, i.e.,
>>allocating gigabytes of DMA RAM, he is going to have to
>>reserve memory that only his driver knows about, using
>>the "mem=" parameter on the boot command line. Then the
>>"extra" RAM above the kernel can be mapped using
>>ioremap_nocache() and made available for DMA and mmap().
>>
> 
> 
> Yeah the reserving of 1.5+G would be difficult in a 32 bit address
> space. But I'm sure there's ways around it.
> 
> He never actually said what his goal was. This could be simply academic,
> I don't know.  But if he got it to work, at least that would be cool.
> (although I would never do such a thing in the "real" world ;-)
> 
> 
> -- Steve
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Peter Chubb]

You may want to take a look at the user-mode driver infrastructure
patches, which do almost exactly what you're trying to do.

Get them from
http://www.gelato.unsw.edu.au/cgi-bin/viewcvs.cgi/cvs/kernel/usrdrivers/kernel-2.6.12-rc3/

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*