Re: question about V4L2_MEMORY_USERPTR on 64bit applications
On Fri, Oct 12, 2018 at 10:52:51AM +0530, tbhar...@codeaurora.org wrote:
> (in 64 bit userspace long is 32-bit)
Not on Linux.
$ cat /tmp/c.c
int main(void)
{
return sizeof(long);
}
$ gcc /tmp/c.c
$ ./a.out; echo $?
8
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.10.0,
BuildID[sha1]=dad78822e741b7900dc7568222822d5d63c31a6c, not stripped
RE: question about V4L2_MEMORY_USERPTR on 64bit applications
64 bit kernel have 64 bit long(not 32 bit), which is not the case with
userspace (in 64 bit userspace long is 32-bit). Probably thig got you confused.
-Original Message-
From: linux-media-ow...@vger.kernel.org On
Behalf Of Zhang, Ning A
Sent: Friday, October 12, 2018 10:03 AM
To: linux-ker...@vger.kernel.org; linux-media@vger.kernel.org
Subject: Re: question about V4L2_MEMORY_USERPTR on 64bit applications
sorry for wrong question, I really meet memory address truncated issue, when
use V4L2 kernel APIs.
in a kernel thread created by kernel_thread() I vm_mmap a shmem_file to addr:
77fa8000 and queue it to V4L2, after dequeue it, and I find the address
is truncated to f7fa8000
I use __u64 {aka long long unsigned int} to save address, and I find userptr is
unsigned long, wrongly think it as "data truncated"
and a lot of __u32 in this structure.
everything works fine, but I still don't understand why high 32bit be 0..
BR.
Ning.
在 2018-10-12五的 11:04 +0800，Zhang Ning写道：
> Hi,
>
> I have question about V4L2_MEMORY_USERPTR on 64bit applications.
>
> struct v4l2_buffer {
> __u32 index;
> __u32 type;
> __u32 bytesused;
> __u32 flags;
> __u32 field;
> struct timeval timestamp;
> struct v4l2_timecodetimecode;
> __u32 sequence;
>
> /* memory location */
> __u32 memory;
> union {
> __u32 offset;
> unsigned long userptr; <<<--- this is a 32bit addr.
> struct v4l2_plane *planes;
> __s32 fd;
> } m;
> __u32 length;
> __u32 reserved2;
> __u32 reserved;
> };
>
> when use a 64bit application, memory from malloc is 64bit address.
> memory from GPU (eg, intel i915) are also 64bit address.
>
> when use these kind of memory as V4L2_MEMORY_USERPTR, address will be
> truncated into 32bit.
>
> this would be error, but actually not. I really don't understand.
>
> BR.
> Ning.
Re: question about V4L2_MEMORY_USERPTR on 64bit applications
sorry for wrong question, I really meet memory address truncated issue,
when use V4L2 kernel APIs.
in a kernel thread created by kernel_thread()
I vm_mmap a shmem_file to addr: 77fa8000
and queue it to V4L2, after dequeue it, and I find the address is
truncated to f7fa8000
I use __u64 {aka long long unsigned int} to save address, and I find
userptr is unsigned long, wrongly think it as "data truncated"
and a lot of __u32 in this structure.
everything works fine, but I still don't understand why high 32bit be
0..
BR.
Ning.
在 2018-10-12五的 11:04 +0800，Zhang Ning写道：
> Hi,
>
> I have question about V4L2_MEMORY_USERPTR on 64bit applications.
>
> struct v4l2_buffer {
> __u32 index;
> __u32 type;
> __u32 bytesused;
> __u32 flags;
> __u32 field;
> struct timeval timestamp;
> struct v4l2_timecodetimecode;
> __u32 sequence;
>
> /* memory location */
> __u32 memory;
> union {
> __u32 offset;
> unsigned long userptr; <<<--- this is a 32bit addr.
> struct v4l2_plane *planes;
> __s32 fd;
> } m;
> __u32 length;
> __u32 reserved2;
> __u32 reserved;
> };
>
> when use a 64bit application, memory from malloc is 64bit address.
> memory from GPU (eg, intel i915) are also 64bit address.
>
> when use these kind of memory as V4L2_MEMORY_USERPTR, address will be
> truncated into 32bit.
>
> this would be error, but actually not. I really don't understand.
>
> BR.
> Ning.
Re: question about V4L2_MEMORY_USERPTR on 64bit applications
Hi, Ning,
unsigned long userptr; <<<--- this is a 32bit addr.
I think it's wrong here,for LP64 data modelmachine(unix-like systems), the
actual size ofdata type 'unsigned long'is 8(64bits value)whichis equal
to pointer.
On 10/12/2018 11:04 AM, Zhang, Ning A wrote:
> Hi,
>
> I have question about V4L2_MEMORY_USERPTR on 64bit applications.
>
> struct v4l2_buffer {
> __u32 index;
> __u32 type;
> __u32 bytesused;
> __u32 flags;
> __u32 field;
> struct timeval timestamp;
> struct v4l2_timecodetimecode;
> __u32 sequence;
>
> /* memory location */
> __u32 memory;
> union {
> __u32 offset;
> unsigned long userptr; <<<--- this is a 32bit addr.
> struct v4l2_plane *planes;
> __s32 fd;
> } m;
> __u32 length;
> __u32 reserved2;
> __u32 reserved;
> };
>
> when use a 64bit application, memory from malloc is 64bit address.
> memory from GPU (eg, intel i915) are also 64bit address.
>
> when use these kind of memory as V4L2_MEMORY_USERPTR, address will be
> truncated into 32bit.
>
> this would be error, but actually not. I really don't understand.
>
> BR.
> Ning.
Re: Question about V4L2_MEMORY_USERPTR
Hi Hans-Petter, On Monday 02 July 2012 21:07:56 Hans Petter Selasky wrote: > Hi Laurent and Sakari, > > For the sake of the matter, here is the driver in question: > http://www.freshports.org/multimedia/webcamd/ > > Under native-Linux (kernel mode): > > I've looked at the linux-media code a bit and it appears that video data is > copied directly from the USB callback functions to the destination process > in userspace. This works because the userspace buffer is mapped into kernel > memory it appears. Correct me if I'm wrong: > > video/videobuf-core.c: > > err = __videobuf_mmap_setup(q, count, size, V4L2_MEMORY_USERPTR); It's hard to tell from that line only. V4L2_MEMORY_USERPTR takes a memory pointer from userspace and uses it in the kernel. How the memory is used depends on the driver, it can be converted to a scatter list of physical memory and passed to the hardware, mapped to the kernel, be accessed using copy_from_user/copy_to_user, ... BTW videobuf1 is outdated, drivers will eventually be ported to videobuf2. > Under FreeBSD where the Linux kernel code is running in user-space as a > driver daemon, this part cannot be done exactly like this, so I've just > patched out the V4L2_MEMORY_USERPTR feature until further. > > Am I clear? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about V4L2_MEMORY_USERPTR
Hi Laurent and Sakari, For the sake of the matter, here is the driver in question: http://www.freshports.org/multimedia/webcamd/ Under native-Linux (kernel mode): I've looked at the linux-media code a bit and it appears that video data is copied directly from the USB callback functions to the destination process in userspace. This works because the userspace buffer is mapped into kernel memory it appears. Correct me if I'm wrong: video/videobuf-core.c: err = __videobuf_mmap_setup(q, count, size, V4L2_MEMORY_USERPTR); Under FreeBSD where the Linux kernel code is running in user-space as a driver daemon, this part cannot be done exactly like this, so I've just patched out the V4L2_MEMORY_USERPTR feature until further. Am I clear? --HPS On Monday 02 July 2012 11:24:15 Laurent Pinchart wrote: > On Sunday 01 July 2012 17:00:58 Sakari Ailus wrote: > > On Fri, Mar 23, 2012 at 08:19:45AM +0100, Hans Petter Selasky wrote: > > > Hi, > > > > > > I have a question about V4L2_MEMORY_USERPTR: > > > > > > From which context are the kernel's "copy_to_user()" functions called > > > in relation to V4L2_MEMORY_USERPTR ? Can this be a USB callback > > > function or is it only syscalls, like read/write/ioctl that are > > > allowed to call "copy_to_user()" ? > > > > > > The reason for asking is that I am maintaining a userland port of the > > > media tree's USB drivers for FreeBSD. At the present moment it is not > > > allowed to call copy_to_user() or copy_from_user() unless the backtrace > > > shows a syscall, so the V4L2_MEMORY_USERPTR feature is simply removed > > > and disabled. I'm currently thinking how I can enable this feature. > > > > I hope this is still relevant --- I just read your message the first > > time. > > > > I don't know how V4L2 is being used in FreeBSD userland, but the intent > > of copy_to_user() function is to copy the contents of kernel memory to > > somewhere the user space has a mapping to (and the other way around for > > copy_from_user()). > > copy_(to|from)_user(), by definition, require a userspace memory context to > perform the copy operation. They can't be called from interrupt context, > kernel threads, or any other context where no userspace memory context is > present. > > > Are your video buffers allocated by the kernel or not? How is USB > > accessed when you don't have the Linux kernel USB framework around? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about V4L2_MEMORY_USERPTR
On Sunday 01 July 2012 17:00:58 Sakari Ailus wrote: > On Fri, Mar 23, 2012 at 08:19:45AM +0100, Hans Petter Selasky wrote: > > Hi, > > > > I have a question about V4L2_MEMORY_USERPTR: > > > > From which context are the kernel's "copy_to_user()" functions called in > > relation to V4L2_MEMORY_USERPTR ? Can this be a USB callback function or > > is it only syscalls, like read/write/ioctl that are allowed to call > > "copy_to_user()" ? > > > > The reason for asking is that I am maintaining a userland port of the > > media tree's USB drivers for FreeBSD. At the present moment it is not > > allowed to call copy_to_user() or copy_from_user() unless the backtrace > > shows a syscall, so the V4L2_MEMORY_USERPTR feature is simply removed and > > disabled. I'm currently thinking how I can enable this feature. > > I hope this is still relevant --- I just read your message the first time. > > I don't know how V4L2 is being used in FreeBSD userland, but the intent of > copy_to_user() function is to copy the contents of kernel memory to > somewhere the user space has a mapping to (and the other way around for > copy_from_user()). copy_(to|from)_user(), by definition, require a userspace memory context to perform the copy operation. They can't be called from interrupt context, kernel threads, or any other context where no userspace memory context is present. > Are your video buffers allocated by the kernel or not? How is USB accessed > when you don't have the Linux kernel USB framework around? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about V4L2_MEMORY_USERPTR
Hi Hans, On Fri, Mar 23, 2012 at 08:19:45AM +0100, Hans Petter Selasky wrote: > Hi, > > I have a question about V4L2_MEMORY_USERPTR: > > From which context are the kernel's "copy_to_user()" functions called in > relation to V4L2_MEMORY_USERPTR ? Can this be a USB callback function or is > it > only syscalls, like read/write/ioctl that are allowed to call > "copy_to_user()" > ? > > The reason for asking is that I am maintaining a userland port of the media > tree's USB drivers for FreeBSD. At the present moment it is not allowed to > call copy_to_user() or copy_from_user() unless the backtrace shows a syscall, > so the V4L2_MEMORY_USERPTR feature is simply removed and disabled. I'm > currently thinking how I can enable this feature. I hope this is still relevant --- I just read your message the first time. I don't know how V4L2 is being used in FreeBSD userland, but the intent of copy_to_user() function is to copy the contents of kernel memory to somewhere the user space has a mapping to (and the other way around for copy_from_user()). Are your video buffers allocated by the kernel or not? How is USB accessed when you don't have the Linux kernel USB framework around? Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
