Access to graphics memory mappings on upcoming WOW64 implementation

[Stefan Dösinger]

Am Montag, 25. April 2022, 08:31:51 EAT schrieb Zebediah Figura:
> - Reserve the entire address space above 2G (or 3G with the appropriate
> image flags). This is essentially what we already do for 32-bit
> programs. I'm not sure if reserving 2**48 bytes of memory will run into
> problems, though? Has this been tried?

Yes, I am doing this in hangover. It does not seem to cost any physical memory 
(for alloc'ing page tables or so), but it takes some time.

What I am doing is this: Try to grab every single page below 4 GB, by 
iterating over them by 4k granularity. Make note in a bitmap which page got 
grabbed that way.

(hangover specific thing: Try to load as many host libs as I think I might need 
to get them above 4 GB to save address space below)

Then mmap 1 << x bytes of memory, starting with x = 64 and decrementing x 
whenever such mmap fails. Throw away the returned pointer.

Then unmap the < 4 GB pages marked in the bitmap.

The stuff that takes time here is reserving / freeing the low 4 GB. Hangover 
process creation takes about 2 seconds due to that, which breaks some kernel32 
tests. The part of actually grabbing all address space above 4 GB is 
relatively fast, I think ~0.5 sec.

If we go this way, we could maybe speed up the process by using the preloader 
to grab the lower 4GB in one block (similarly to the page zero thing on 
macos).

One drawback is that it makes it much harder to use the address space above 4 
GB. We *want* that space, just not if we may have to pass a pointer to it to 
32 bit code...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220425/f06f9810/attachment.sig>