RPi 4B 4G 32 位操作系统上的 qemu-x86_64

如何解决RPi 4B 4G 32 位操作系统上的 qemu-x86_64

我正在尝试使用 qemu-x86_64 在我的 RPi 4B 上运行 x86_64 playonlinux。我在 32 位操作系统上。运行时报错如下：

(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 支持等其他领域相比。）

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

首先列出可能的原因：QEMU 的用户模式不支持 32 位主机上的 64 位客户机。我们尽最大努力，这对简单的程序有效，但对于更复杂的程序可能会失败。您可以通过查看程序是否在 x86-64-on-aarch64 等 64-on-64 组合上运行来测试这是否是问题。

其次，我们的 x86-64 仿真并没有像 AVX 那样涵盖 x86 指令集的更新；如果来宾程序假定它可以使用这些，那么在 QEMU 下运行时它会崩溃或行为不端。 （这里的错误看起来可能不是这个。）

第三，我们可能在执行特定系统调用或 Linux ABI 的其他功能时遗漏或存在错误。

第四，x86 内存模型比 Arm 更严格，QEMU 的仿真并没有试图弥补这一点。因此，如果您不走运，多线程访客程序可能会在这里遇到问题。

追踪这个特定来宾二进制文件中哪些可能是这种情况需要一个扩展的调试会话，您可以在其中查看来宾在失败时正在做什么（例如，为什么 shmat() 失败？总线错误的直接原因是什么？）然后尝试使用来宾源、来宾二进制文件的反汇编/逆向工程和 QEMU 源的组合来回溯发生的事情。 （如果你觉得这是一个艰难而漫长的过程，你没有错:-))

旁注：图形程序上“shmat 失败”加上“总线错误”的组合让我怀疑您的设置是否使用远程 X 会话（DISPLAY 设置为本地 X 服务器以外的其他内容）和来宾程序本身有问题，无法成功回退到不使用 X 共享内存扩展的代码路径。您可以通过在具有非本地 DISPLAY 设置的 x86-64 主机上本机运行来宾，或安排在您的 Arm 主机上安装本地 X 服务器来测试这一点。

,

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