(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML

[Tony.LI]

First I creat a file system that is debian(bullseye amd64)on arm64 machine，then I download google-chrome，however, when I ran Google browser, some errors occurred.

$ google-chrome --no-sandbox
or
$ qemu-x86_64-static google-chrome --no-sandbox

qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes)
[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes)
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
[1637:1678:0806/074308.337567:ERROR:file_path_watcher_linux.cc(315)] inotify_init() failed: Function not implemented (38)
Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
qemu: unknown option 'type=utility'
[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
Trace/breakpoint trap

Why?
And then I run firefox,it can be opened, but it can't load any web pages and HTML.
I really need help！
Thank.

[Tony.LI (bigboy0822)]

When I run some app,like google-chrome:

  qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped

[Peter Maydell (pmaydell)]

Which QEMU version are you using ?

[Tony.LI (bigboy0822)]

Hi Peter,I use 5.1.0-rc3.

[Tony.LI (bigboy0822)]

It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So what is the problem?

[Alex Bennée (ajbennee)]

Tony.LI <email address hidden> writes:

> It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So
> what is the problem?

Could be a number of things - is Chrome using threading alongside it's
multiple processes?

--
Alex Bennée

[Tony.LI (bigboy0822)]

Hi,Alex.May be you are right.I don't understand what you want to express.
I don't know what causes traps.
Is it caused by software, or qemu executes CPU-sensitive instruction simulation.

[Alex Bennée (ajbennee)]

Tony.LI <email address hidden> writes:

> Hi,Alex.May be you are right.I don't understand what you want to express.
> I don't know what causes traps.
> Is it caused by software, or qemu executes CPU-sensitive instruction simulation.

Does it work if you run:

  taskset 1 qemu-x86_64 google-chrome

--
Alex Bennée

[Tony.LI (bigboy0822)]

Hi,Alex.It can't work.And I find some thing:

$ glxinfo | grep -i open

radeon: Failed to get PCI ID, error number -38
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi
libGL error: failed to get magic
libGL error: failed to load driver: radeonsi
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

So，could it be a problem with the PCI? I see a lot of questions about PCI when use qemu-system.But，what should I do?And I use qemu-user like qemu-x86_64-static.

[Tony.LI (bigboy0822)]

$ lspci
00:00.0 PCI bridge: Cadence Design Systems, Inc. Device dc16
00:01.0 PCI bridge: Cadence Design Systems, Inc. Device dc08
00:02.0 PCI bridge: Cadence Design Systems, Inc. Device dc01
00:03.0 PCI bridge: Cadence Design Systems, Inc. Device dc16
00:04.0 PCI bridge: Cadence Design Systems, Inc. Device dc08
00:05.0 PCI bridge: Cadence Design Systems, Inc. Device dc01
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (rev 87)
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series]
03:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 11)
06:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)

Outside chroot,I get the same infomation!
Why? "radeon: Failed to get PCI ID, error number -38"

[Tony.LI (bigboy0822)]

And I can get some infomation by "qemu-x86_64-static -d strace".

....
17344 getdents(8,274880624768,32768,115,274880624899,39) = 0
17344 close(8) = 0
17344 ioctl(7,0xc0406400,0x297330) = 0
17344 ioctl(7,0xc0406400,0x297330) = 0
17344 fstat(7,0x0000004001a0b660) = 0
17344 fcntl(7,F_DUPFD_CLOEXEC,3) = 8
17344 ioctl(8,0xc0406400,0x297330) = 0
17344 ioctl(8,0xc0406400,0x297330) = 0
17344 ioctl(8,0xc0106467,0x1a0b700) = -1 errno=38 (Function not implemented)
....

Last ioctl is error,why?It drives me crazy!!!

[Peter Maydell (pmaydell)]

ioctl number 0xc0106467 is DRM_IOCTL_RADEON_INFO. QEMU doesn't support that ioctl (each ioctl needs individual handling to convert the data structures it uses between the guest and host architecture). If your guest binary is trying to make graphics-card specific ioctl calls like this then I'm afraid it won't work in QEMU (unless somebody writes the QEMU patch to make it support them).

[Tony.LI (bigboy0822)]

Hi,I added a patch for ioctl(), and in the system call, I found no other errors, but it still doesn't work.And，I use the "qemu-x86_64 -d unimp xxx" command,I found this error:

    Unknown QEMU_IFLA_INFO_KIND sit

In the Qemu source code:
linux-user/fd-trans.c
....
    /* nested */
    case QEMU_IFLA_INFO_DATA:
        if (strncmp(li_context->name, "bridge",
                    li_context->len) == 0) {
            return host_to_target_for_each_nlattr(NLA_DATA(nlattr),
                                                  nlattr->nla_len,
                                                  NULL,
                                             host_to_target_data_bridge_nlattr);
        } else if (strncmp(li_context->name, "tun",
                    li_context->len) == 0) {
            return host_to_target_for_each_nlattr(NLA_DATA(nlattr),
                                                  nlattr->nla_len,
                                                  NULL,
                                                host_to_target_data_tun_nlattr);
        } else {
            qemu_log_mask(LOG_UNIMP, "Unknown QEMU_IFLA_INFO_KIND %s\n",
                          li_context->name);
        }
        break;

....

What does it mean?
And how can i solve it?
Thank you!!!

[Laurent Vivier (laurent-vivier)]

Could you try attached patch?

[Tony.LI (bigboy0822)]

Hi,I have add QEMU_IFLA_INFO_KIND nested type for sit.But I still can't open Google browser.
And there are still the following errors:

qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes)
[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes)
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
qemu: unknown option 'type=utility'
[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
Trace/breakpoint trap

Qemu get the signal(INT3).
What causes this signal???

I don't know how to debug. When I block the operation of int3 in QEMU, it has the following error:

qemu: 0x4004bc7855: unhandled CPU exception 0x3 - aborting
RAX=953ad79643deb400 RBX=0000007fa1203140 RCX=953ad79643deb400 RDX=000000400863f1d8
RSI=0000004000b33f18 RDI=000000000000000e RBP=000000400863f590 RSP=000000400863f3c0
R8 =0000000000000000 R9 =0000000000000001 R10=0000000000000000 R11=000000400aa153c0
R12=000000400863f5a0 R13=0000000000000000 R14=0000007fa1218e10 R15=000000400863f5a0
RIP=0000004004bc7855 RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 00000000 00000000
CS =0033 0000000000000000 ffffffff 00effb00 DPL=3 CS64 [-RA]
SS =002b 0000000000000000 ffffffff 00cff300 DPL=3 DS [-WA]
DS =0000 0000000000000000 00000000 00000000
FS =0000 000000400c0c3840 00000000 00000000
GS =0000 0000000000000000 00000000 00000000
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT= 000000400866f000 0000007f
IDT= 000000400866e000 F000001ff
CR0=80010001 CR2=0000000000000000 CR3=0000000000000000 CR4=00000220
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000500

Is it possible that the CPU of arm does not support certain instructions?But，I don't know.
Who can give me some advice?
Thank you！

[Tony.LI (bigboy0822)]

I wrote an example to load local HTML:

#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QWebEngineView>
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);

    QWebEngineView *webView = new QWebEngineView(this);

    webView->load(QUrl("file:////home/tony/1.html"));
    webView->setFixedSize(this->width(),this->height());
    webView->show();
}

MainWindow::~MainWindow()
{
    delete ui;
}

At the same time, I found that a process(QtWebEngineProcess) did not start properly;
Then,I run:

    $ ./QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV
    qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped

    But,I didn't find any mistakes.Why does the process exit?

[Tony.LI (bigboy0822)]

Now, I found something new when I use gdb:

=> 0x400523c858: ud2
   0x400523c85a: pushq $0xd
   0x400523c85c: mov -0x230(%rbp),%rax
   0x400523c863: mov -0x240(%rbp),%rdi
   0x400523c86a: mov $0x1,%esi
   0x400523c86f: movq $0x0,-0x230(%rbp)
   0x400523c87a: mov %rax,-0x220(%rbp)
   0x400523c881: callq 0x40051ccf00
   0x400523c886: callq 0x400266c540
   0x400523c88b: cmp $0x1,%eax
   0x400523c88e: je 0x400523c8ed
   0x400523c890: lea -0x220(%rbp),%rdi
   0x400523c897: callq 0x40040fe8e0
   0x400523c89c: jmpq 0x400523c60c
   0x400523c8a1: int3
   0x400523c8a2: ud2
   0x400523c8a4: pushq $0x10
   0x400523c8a6: int3
   0x400523c8a7: ud2
   0x400523c8a9: pushq $0x11
   0x400523c8ab: mov -0x200(%rbp),%rax
   0x400523c8b2: lea -0x1c0(%rbp),%rbx
   0x400523c8b9: movq $0x0,-0x200(%rbp)

[Wind Li (nightwend)]

I found out the reason for "qemu: unknown option 'type=utility'", created a sample code to demo it and a small wrokaround patch to chromium. Found more info in:
https://bugs.launchpad.net/qemu/+bug/1926246

[Thomas Huth (th-huth)]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/280