Hi,
The compatible ioctl is missing for submitting URB from 32 bit
application on a x86_64 system. For people who need to refresh
their mind, please read the big comment after do_usbdevfs_bulk
in fs/compat_ioctl.c
VMware is a big user of the usbdevfs, we translate guest USB
IO to usbdevfs, by submitting URB. On the x86_64 system, we
need those compatible ioctl for submitting URBs. For now we
make a hack to submit it through the vmmon driver. But that
is very ugly.
I do want this problem get fixed in the linux kernel eventually.
I have been toying with two different ways to solve it. It seems
that it is unavoidable to get hands dirty in the usbdevfs internals.
The first one is just educate the usbdevfs to know about the 32 bit
URB ioctls. So it don't need to keep around a bounce buffer.
The second idea is have a bounce buffer, and let the usbdevfs internals
to know about his bounce buffer and free it when the async structure
destroyed (except for reap).
I attach a patch just implement the first approach. Any comment are
welcome.
Chris
On Fri, 2005-01-28 at 16:23 -0500, Christopher Li wrote:
> +#ifdef CONFIG_IA32_EMULATION
> +
> + case USBDEVFS_SUBMITURB32:
> + snoop(&dev->dev, "%s: SUBMITURB32\n", __FUNCTION__);
> + ret = proc_submiturb_compat(ps, p);
> + if (ret >= 0)
> + inode->i_mtime = CURRENT_TIME;
> + break;
> +#endif
Why don't other 64bit architectures need this chunk?
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
This patch is for the case that running 32 bit application on
a 64 bit kernel. So far only x86_64 allow you to do that.
I am not aware of other 64bit architecture need the 32bit
emulation.
Chris
On Sat, Jan 29, 2005 at 04:29:51AM +0000, Gianni Tedesco wrote:
> On Fri, 2005-01-28 at 16:23 -0500, Christopher Li wrote:
> > +#ifdef CONFIG_IA32_EMULATION
> > +
> > + case USBDEVFS_SUBMITURB32:
> > + snoop(&dev->dev, "%s: SUBMITURB32\n", __FUNCTION__);
> > + ret = proc_submiturb_compat(ps, p);
> > + if (ret >= 0)
> > + inode->i_mtime = CURRENT_TIME;
> > + break;
> > +#endif
>
> Why don't other 64bit architectures need this chunk?
>
> --
> // Gianni Tedesco (gianni at scaramanga dot co dot uk)
> lynx --source http://www.scaramanga.co.uk/scaramanga.asc | gpg --import
>
Christopher> This patch is for the case that running 32 bit
Christopher> application on a 64 bit kernel. So far only x86_64
Christopher> allow you to do that.
Actually, at least ia64, mips, parisc, ppc64, s390 and sparc64 also
support 32-bit applications on a 64-bit kernel. All of those
architectures except s390 can use USB. I guess vmware doesn't run on
most of those architectures but any solution in the mainline kernel
should be generic enough to handle them all.
- R.
On Fri, Jan 28, 2005 at 08:33:05PM -0500, Christopher Li wrote:
> This patch is for the case that running 32 bit application on
> a 64 bit kernel. So far only x86_64 allow you to do that.
>
> I am not aware of other 64bit architecture need the 32bit
> emulation.
Huh???
a) ppc64 runs ppc32 userland
b) sparc64 runs sparc32 userland (as the matter of fact, very
few userland programs are normally built 64bit there - no benefits in
doing that for most applications, it only bloats the memory footprint)
c) mips64 runs mips32 userland
d) itanic, IIRC, runs i386 userland
e) s390x runs s390 userland
f) parisc64 runs parisc32 userland
It's normal situation, not an exception. The only pair I'm not sure about
is sh64/sh. AFAICS, the only other supported 64bit platform without 32bit
emulation is alpha - and in that case there's no corresponding 32bit
processor to emulate.
Christopher Li <[email protected]> writes:
> This patch is for the case that running 32 bit application on
> a 64 bit kernel. So far only x86_64 allow you to do that.
>
> I am not aware of other 64bit architecture need the 32bit
> emulation.
A lot of them do. Just use CONFIG_COMPAT instead.
-Andi
Christopher Li <[email protected]> writes:
> VMware is a big user of the usbdevfs, we translate guest USB
> IO to usbdevfs, by submitting URB. On the x86_64 system, we
> need those compatible ioctl for submitting URBs. For now we
> make a hack to submit it through the vmmon driver. But that
> is very ugly.
>
> I do want this problem get fixed in the linux kernel eventually.
> I have been toying with two different ways to solve it. It seems
> that it is unavoidable to get hands dirty in the usbdevfs internals.
> The first one is just educate the usbdevfs to know about the 32 bit
> URB ioctls. So it don't need to keep around a bounce buffer.
Looks reasonable from a first look.
Issues:
- Should use CONFIG_COMPAT, not x86-64 specific symbols
- Why can't you set URB_COMPAT transparently in the emulation
layer? Then existing applications would hopefully work without
changes, right?
You may also want to preserve the __user casts, otherwise
Al Viro and other sparse users will be unhappy.
Thanks for attacking this long standing problem.
-Andi
It is nice to know all that. I guess I did not know much about
the other 64 bit systems. I will update and resend my patch.
Thanks!
Chris
On Fri, Jan 28, 2005 at 09:45:38PM -0800, Roland Dreier wrote:
> Christopher> This patch is for the case that running 32 bit
> Christopher> application on a 64 bit kernel. So far only x86_64
> Christopher> allow you to do that.
>
> Actually, at least ia64, mips, parisc, ppc64, s390 and sparc64 also
> support 32-bit applications on a 64-bit kernel. All of those
> architectures except s390 can use USB. I guess vmware doesn't run on
> most of those architectures but any solution in the mainline kernel
> should be generic enough to handle them all.
>
> - R.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
>
> Looks reasonable from a first look.
>
> Issues:
> - Should use CONFIG_COMPAT, not x86-64 specific symbols
Agree.
> - Why can't you set URB_COMPAT transparently in the emulation
> layer? Then existing applications would hopefully work without
> changes, right?
The existing application is don't need to set the USB_COMPAT flag.
It is use internally to track the URB is submit from 32 bit user
space. I guess I don't have to use that flag.
>
> You may also want to preserve the __user casts, otherwise
> Al Viro and other sparse users will be unhappy.
I did try. Which place are you referring to? I guess miss some of
it.
Chris
>
> Thanks for attacking this long standing problem.
>
> -Andi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Jan 29, 2005 at 07:33:31AM +0100, Andi Kleen wrote:
> Issues:
> - Should use CONFIG_COMPAT, not x86-64 specific symbols
Fixed.
> - Why can't you set URB_COMPAT transparently in the emulation
> layer? Then existing applications would hopefully work without
> changes, right?
Now I see it. That is not what I intent. I must misplace it.
I remove the USB_COMPAT in the new patch any way. It looks
cleaner.
> You may also want to preserve the __user casts, otherwise
Not sure where it is. But I need to verify this patch on Monday.
I don't have an AMD 64 at home.
Thanks.
Chris