Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Sep 2012 12:19:14 -0000
From:      Meowthink <meowthink@gmail.com>
To:        <rnejdl@ringofsaturn.com>
Cc:        freebsd-x11@freebsd.org, freebsd-emulation@freebsd.org
Subject:   Re: [CFT]Patch for dri / drm interoperability i386 world / amd64 kernel
Message-ID:  <CABnABobMbR=Zp5Ppd6heVO9mV7iqmBxuZ4RMr9zXP441-mRSXQ@mail.gmail.com>
In-Reply-To: <20120818190225.GF33100@deviant.kiev.zoral.com.ua>
References:  <CABnABoZKENJqcoQbkw6A0hJY_YY6Y0-FUM6GghtE%2Ba4wH7GwVA@mail.gmail.com> <20120818190225.GF33100@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 19, 2012 at 3:02 AM, Konstantin Belousov
<kostikbel@gmail.com> wrote:
> On Sat, Aug 11, 2012 at 09:25:09AM +0800, Meowthink wrote:
>> Hello all,
>>
>> So long FreeBSD's DRI implementation lacks of i386/amd64
>> interoperability, as discussed [0] [1]. This breaks wine, linuxulator
>> etc. drawing using DRI-based OpenGL.
>> Paul Mackerras et al. actually did that part for Linux implementation,
>> so I simply translated their work to FreeBSD. Due to my poor
>> programming skills, there's some limitations:
>> 0. I tried to split compatible codes into separate files, like under
>> Linux. But as a result of the difference between FreeBSD and Linux,
>> the code is integrated in a  "#include ...ioc32.c" form which is not
>> so elegant.
>> 1. For same reason, struct drm_driver_info has to be changed.
> I fixed 0 and 1 to my liking and committed the patch.
>
> Thank you.
>
>> 2. There should be some assertions if a 64-bit pointer failed to fit
>> in a 32-bit space. Linux implementation didn't do this either, but
>> they're guaranteed by user-space ioctl structures. This may result
>> unstable under heavy load.
> I am not sure what do you mean exactly. Can you elaborate, please ?

Excuse me for my poor expression. What I mean is, for example, line
177-180 in sys/dev/drm2/drm_ioc32.c reads:

        handle = map.handle;
        m32->mtrr = map.mtrr;

        m32->handle = (unsigned long)handle;

drm_map.handle will be a 64-bit pointer under 64-bit mode, so I wonder
this needs verification? But Linux version of drm didn't verify:

        if (__get_user(m32.offset, &map->offset)
            || __get_user(m32.size, &map->size)
            || __get_user(m32.type, &map->type)
            || __get_user(m32.flags, &map->flags)
            || __get_user(handle, &map->handle)
            || __get_user(m32.mtrr, &map->mtrr))
                return -EFAULT;

        m32.handle = (unsigned long)handle;
        if (copy_to_user(argp, &m32, sizeof(m32)))
                return -EFAULT;

In this case, drm_addmap(drm_bufs.c) guarantee the handle always a
32-bit integer, with 0s only in high 32 bits on amd64. But I'm not
very sure that all kinds of this pointer operations, esp. those
buffer-related address ops can guarantee a 32-bit pointer in all
cases.

Thanks for your review.
Meowthink
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABnABobMbR=Zp5Ppd6heVO9mV7iqmBxuZ4RMr9zXP441-mRSXQ>