Access to graphics memory mappings on upcoming WOW64 implementation

[Matteo Bruni]

On Tue, Apr 26, 2022 at 12:04 AM Chris Robinson <chris.kcat at gmail.com> wrote:
>
> On Sunday, April 24, 2022 7:18:49 PM PDT Derek Lesho wrote:
> > The solutions which I've seen laid out so far:
> >
> > - Use the mremap(2) interface, allowing us to duplicate the mapping we
> > receive into the 32-bit address space.  This solution would match what
> > is already done for Crossover Mac's 32on64 support using Mac's
> > mach_vm_remap functionality [2].  However, right now it is not possible
> > to use the MREMAP_DONTUNMAP flag with mappings that aren't private and
> > anonymous, which rules out there use on mapped FDs from libdrm.  Due to
> > this, a kernel change would be necessary.
>
> This doesn't sound at all safe, since it's essentially moving the memory
> mapping out from under the driver. MREMAP_DONTUNMAP avoids unmapping the
> original memory space, but that memory space becomes all but invalid, a page
> fault when accessed and is otherwise zero-filled to satisfy accesses:
>
>     MREMAP_DONTUNMAP (since Linux 5.7)
>         ...
>         After completion, any access to the range specified by old_address and
>         old_size will result in a page fault. The page fault will be handled
>         by a userfaultfd(2) handler if the address is in a range previously
>         registered with userfaultfd(2). Otherwise, the kernel allocates a
>         zero-filled page to handle the fault.
>
> You can't know what a driver will do with mapped memory or pointer addresses
> it returns to the application, or where such memory comes from, so you can't
> be sure it doesn't have some bookkeeping with it or does manual copying using
> a cached pointer instead of the remapped location. You also can't know if it's
> using a preallocated pool that it returns to the app when "mapping" and reuses
> after "unmapping".
>
> What you'd need for something like this is a method to duplicate a memory
> mapping, leaving the original intact instead of wiping it, so different pages/
> addresses refer to the same underlying hardware memory. There doesn't seem to
> be an option for that, currently.

Indeed, that's what CrossOver's macOS hack does at the moment, by
means of the mach_vm_remap() API. It sounds like currently there is no
equivalent functionality in Linux. I have no clue if the Linux memory
management infrastructure makes supporting that particularly hard, but
otherwise I wouldn't expect any particular opposition on a matter of
principle to introducing the support we need into the kernel.

Personally I find this to be the only really practical strategy, at
least among those that have been mentioned. As Zeb pointed out, that's
not to say there won't be any use in also pursuing other options
though.