qemu-x86_64 树莓派 4B 4G 32 位 OS

qemu-x86_64 on RPi 4B 4G 32-bit OS

我正在尝试 运行 x86_64 在我的 RPi 4B 上使用 qemu-x86_64 playonlinux。我在 32 位 OS 上。这是 运行 宁它时的错误:

(xenial-amd64)pi@raspberrypi44g:~/chroots/64-bit-x86 $ playonlinux        
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Looking for python... 2.7.12 - wxversion(s): 3.0-gtk2
selected
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[main] Message: PlayOnLinux (4.2.10) is starting
[clean_tmp] Message: Cleaning temp directory
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[Check_OpenGL] Warning: check_dd_x86 missing, test skipped
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[Check_OpenGL] Warning: check_dd_amd64 missing, test skipped
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[POL_System_CheckFS] Message: Checking filesystem for /home/pi/.PlayOnLinux/
[main] Message: Filesystem is compatible
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

(mainwindow.py:12318): Gdk-WARNING **: shmat failed: error 22 (Invalid argument)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/usr/share/playonlinux/playonlinux: line 126: 12318 Bus error               "$POL_PYTHON"             mainwindow.py "$@"
(xenial-amd64)pi@raspberrypi44g:~/chroots/64-bit-x86 $ [update_check] Message: List is up     to date
[install_plugins] Message: Checking plugin: ScreenCap...
[install_plugins] Message: Checking plugin: PlayOnLinux Vault...

(xenial-amd64)pi@raspberrypi44g:~/chroots/64-bit-x86 $ 

导致此错误的原因是什么?

这里有几个可能的原因,但总的来说 QEMU 的用户模式模拟远非完美,最好不要指望它能够 运行 大型和复杂的软件,尤其是类似于 PlayOnLinux,AFAICT 基于 Wine。 (在 QEMU 开发者社区的有效优先级列表中,用户模式仿真不是很高,因为没有多少开发者花钱从事这部分代码的工作,或者出于个人原因从事这部分代码的开发人员并不多。兴趣,与系统仿真或 KVM 支持等其他领域相比。)

我将从第 0 项开始,即您没有说明您使用的 QEMU 版本。如果不是最新版本,您可以尝试更新的 QEMU,看看是否有帮助。

可能原因列表中的第一个:QEMU 的用户模式不支持 32 位主机上的 64 位来宾。我们尽最大努力,这适用于简单的程序,但对于更复杂的程序可能会失败。您可以通过查看程序是否 运行s 在 x86-64-on-aarch64.

等 64-on-64 组合上来测试这是否是问题所在

其次,我们的 x86-64 仿真不涵盖最近添加到 x86 指令集的内容,例如 AVX;如果来宾程序假设它可以使用那些,那么它会在 QEMU 下 运行 时崩溃或行为不端。 (这里的错误看起来可能不是这个。)

第三,我们可能在特定系统调用或 Linux ABI 的其他功能的实现中遗漏或存在错误。

第四,x86内存模型比Arm内存模型更严格,QEMU的仿真并没有试图弥补这一点。因此,如果您不走运,多线程来宾程序可能 运行 会在此处出现问题。

要找出对于这个特定的来宾二进制文件可能是哪种情况,需要一个扩展的调试会话,您可以在其中查看来宾在失败时正在做什么(例如,为什么 shmat()失败?总线错误的直接原因是什么?),然后尝试使用来宾源、来宾二进制文件的 disassembly/reverse-engineering 和 QEMU 源的组合来追溯发生的事情。 (如果您觉得这是一个艰难而漫长的过程,那您就没错 :-))

旁注:图形程序上“shmat 失败”和“总线错误”的组合让我想知道您的设置是否正在使用远程 X 会话(DISPLAY 设置为本地 X 服务器以外的其他内容)和来宾程序本身有问题,无法成功回退到不使用 X 共享内存扩展的代码路径。您可以通过 运行 在具有非本地 DISPLAY 设置的 x86-64 主机上原生地连接来宾,或者通过在您的 Arm 主机上安排一个本地 X 服务器来测试它。

它有效,但不是很好。如果可以,请使用 x86_64 主机系统。