linux-kernel - Re: [PCI Driver]Physical address being returned as 0 in mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTimAHc6+ZPd7gUpr0-eHGpyLSwJFEA@mail.gmail.com>
Date:	Sat, 2 Jul 2011 12:24:08 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	newton mailinglist <newtonmailinglist@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PCI Driver]Physical address being returned as 0 in mmap

Please reply inline, top-posting is unwelcome on LKML.

On Sat, Jul 2, 2011 at 11:27, newton mailinglist
<newtonmailinglist@...il.com> wrote:
> ok thanks Kyle, I will try the DMA API now.
>
>  I was wondering, when my driver gets the mmap() call then has the
>  kernel already allocated memory and put its details in the vma
>  parameter or do I need to allocate memory myself ?

Hmm, I'm not exactly clear what you are asking here... I would need
to see your driver code to be able to give you better advice, but let
me give it a shot anyways:

The "vma" is a vm_area_struct which describes the user side of the
memory-map, and in your "mmap()" call you essentially populate that
"vma" with information about the physical CPU memory addresses.
Typically that means memory allocated with dma_alloc_coherent(),
and I think the DMA API docs have some example code for this.

> I am already using the driver read and write functions to read/write
> some other parameters to the FPGA, so I will setup the DMA in mmap()

The reason I suggest read()/write() is because you are talking about
using mmap() and then doing memcpy(), whereas if you implement
your read()/write() handlers properly then you might not need to do
a memcpy() at all.

If you're just using read()/write() for parameter data, I would switch
those to an ioctl() call and use read()/write() for your bulk data transfer.
Even if you elect to use mmap() the way you have described, you
will still need to implement some ioctl() calls to allow your userspace
program to trigger the appropriate dma_sync_*() API calls on the
memory when communicating with the hardware.

Ideally, for streaming large amounts of data out of a device, you
would call read() from the device onto a large multiple-page buffer
in your userspace program.  The userspace addresses get passed
down into your kernel driver, and you use the appropriate APIs to
get the page structs for those addresses and directly DMA-map
those pages.

That means that in the best case your device will read directly into
user memory.  If the user memory is not accessible to your device
then the kernel will use the "swiotlb" driver to bounce-buffer it for
you.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/