I followed the link, running hangover/scripts/hangover-test.sh is ok, I got these errors when I specified the running program.
chj@ROCm:~/hangover$ ./build/wine-host/wine64 build/qemu/x86_64-windows-user/qemu-x86_64.exe.so build/wine-guest/programs/notepad/notepad.exe 0009:fixme:qemu_module:import_dll No implementation for user32.dll.SetProcessDpiAwarenessInternal imported from L"C:\\windows\\system32\\shcore.dll", setting to 0xffff89557e40 0009:fixme:qemu_module:import_dll No implementation for ntdll.dll._setjmp imported from L"C:\\windows\\system32\\windowscodecs.dll", setting to 0xffff89557e40 0009:fixme:qemu_module:import_dll No implementation for ntdll.dll.longjmp imported from L"C:\\windows\\system32\\windowscodecs.dll", setting to 0xffff89557e40 .exe.so: /home/chj/hangover/qemu/windows-user/main.c:647: qemu_execute: Assertion h2g_valid(ret_code)' failed.
Exception triggered in host code at 0xffff8bd374d8, guest PC fff0
wine: Assertion failed at address 0xffff8bd374d8 (thread 0009), starting debugger...
0x0000ffff8bd374d8 _IO_proc_close+0xffffffffffffffff in libc.so.6: be_arm64_disasm_one_insn: not done
A quick note re hangover-test.sh: It isn't a self-test script, but a helper script to run the Wine tests inside hangover. Running it on its own will not do much. Have a look inside it to see what is does.
This is the problem I encountered when running the Huawei server TaiShan2280. I found the reason for triggering the assertion. The value of ret_code on Huawei TaiShan2280 is within 48 bits (281474976710656-1), which exceeds the limit of 47 (140737488355328-1) of GUEST_ADDR_MAX. hangover/qemu/target/i386/cpu.h can be run normally after line 1703 being modified to 48 bits.
#define TARGET_VIRT_ADDR_SPACE_BITS 47
change into
#define TARGET_VIRT_ADDR_SPACE_BITS 48
I compiled and run on two machines, one is firefly3399 (cpu: rk3399, dual core cortex a72, quad core cortex a53), another one is Huawei server TaiShan2280 (cpu: hi1616, 32 core cortex a72), on firefly3399 Running normally, there was a problem running in TaiShan2280. I found out that the value of the variable ret_core on TaiShan2280 exceeded the maximum virtual address of the variable MAX by 47 bits on the TaiShan2280, causing the assertion. I changed the value of MAX to 48. I am not very familiar with this aspect. I would like to know what causes the difference in the number of virtual memory addresses on different machines,What bad effect will it cause after changing to 48 bits? Because the WINE and QEMU parts of HANGOVER need to be modified at the same time, by the way, WINE's bug is in question. Version 3.0 has been proposed, why haven't seen the fix on the latest version of WINE or hangover?
The following are the running logs of firefly3399 and TaiShan2280 after printing the relevant variable values (I have changed MAX to 48 bits on TaiShan2280)
log-rk3399.txtlog-huawei.txt
I vaguely remembered I replied to this question a long time ago, but apparently I did not...
The short answer is that setting TARGET_VIRT_ADDR_SPACE_BITS to 64. Qemu's linux-user uses it to make sure it does not pass a pointer to the guest code that is higher than it expects. It reflects the usual address space split of the guest system. E.g. on 32 bit Windows, the address space is split into 2 GB Userspace and 2 GB kernel space. No pointer returned from a Win32 function will have the highest bit set (TARGET_VIRT_ADDR_SPACE_BITS=31 in this case), so some applications abuse the highest bit for their internal purposes. If hangover gives the application a pointer above 0x7fffffff this might break. See also the large address aware flag for a Windows-specific related issue.
Other parts in Wine and hangover take care of this, so we don't need qemu's infrastructure and can just tell it that the full 64 bit address space is fine.
aarch64 linux doesn't have a universally agreed address space size. It depends on compile time kernel parameters (page size, 3 level paging). x86_64 Windows has 47 bits.