Re: [PATCH v8 0/9] MR6: Avoid performance degradation due to vDSO unmapping (BZ#52313)

[Kevin Puetz (＠puetzk)]

> We cannot reliably detect presence of QEMU

When I said "it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using", the "it" I had in mind was that qemu-user should do that, not wine-preloader. As you say, wine-preloader doesn't have a good way to know it's running inside qemu. qemu could see that executing this MAP_FIXED would trample on the host proces in ways that compromise the interpreter, and it could choose to make the mmap syscall return MAP_FAILED.
> I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures.

I'm actually doing the opposite, which has to be even more niche. We're using qemu-user and binfmt_misc to run unit tests of an aarch64 executable (built with wineg++) on our x86_64 CI server, as part of cross-compiling. This kind of usage has to be vanishingly rare (winelib seems quite rare period).

Sorry to have started a somewhat offtopic thread with my comment here. I don't directly think there's much for wine-preloader to do about this. I just stumbled on this merge request in the course of debugging my crash, and was in the same area, and made me think of more alternatives. I had forgotten that using mremap to move `[vdso]` out of the way might even be an option. The main connection is that if this MR makes wine ask to move the vdso out of the way (rather than just having MAP_FIXED clobber it), that seems like something qemu-user might be able to implement and carry on. Just clobbering it seems much harder to tolerate.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2890