NetBSD/aarch64 on VMware: status report

[PHO <pho%cielonegro.org@localhost>]

Hi,

I recently installed NetBSD/aarch64 10.0 as a VMware guest on my system. 
I'm gonna tell you how it went, in case it helps for someone doing the same.


* Background

I've been running NetBSD/amd64 as a VM guest on my Intel iMac for years. 
This is because I need to use both NetBSD and MacOS at the same time. 
However some bad sectors recently showed up in the HDD on my 8-years-old 
iMac, which isn't too surprising though. Since it's extremely difficult 
(if not impossible) to replace any components inside iMacs, and Apple 
discontinued Intel Macs, I had to buy an M3 Mac as a replacement and 
transfer my data immediately. This meant my NetBSD/amd64 VM guest also 
had to migrate to aarch64.

Nearly everything worked well on my new M3 Mac thanks to you guys who 
have worked hard to port NetBSD to this awesome architecture. But there 
were a few problems that I needed to work around.


* Occasional lock ups on NVMe virtual disks

Recent versions of VMware expose virtual disks as NVMe devices by 
default, but there seems to be an issue in NetBSD 10.0 in this regard. 
When a user process performs any significant amount of disk I/O, it has 
a non-negligible chance that the process hangs up in the tstile state. 
There must be a race condition or some locking issues in 10.0 kernel. 
I'll try -CURRENT and see if the problem persists.

One can work around the issue by simply changing the bus type of virtual 
disks to SATA.


* xf86-video-wsfb is the only X.org video driver we can use

On NetBSD/amd64 we can use xf86-video-vmware. In combination with 
sysutils/open-vm-tools we can change the resolution of X.org server 
dynamically by resizing the VMware window or by going into fullscreen, 
even without my pending patches[1] to DRM/KMS for supporting 3D 
acceleration. However, the upstream seems to have abandoned the driver 
and it only works on x86 and amd64. This is because the driver only 
supports SVGA v1 and v2 but VMware does not provide these interface 
versions on aarch64. SVGA v3 is the only interface it provides, which 
means we have to update our DRM/KMS and port its vmwgfw driver again to 
NetBSD. vmware-user(1) from open-vm-tools can only do its things when 
it's running either on Wayland with a proper DRM/KMS support from kernel 
or on xf860-video-vmware, which accepts certain requests from 
open-vm-tools and redirects them to SVGA using libpciaccess.

Although we can still use xf86-video-wsfb but it's of course suboptimal, 
because 1024x768 is the best resolution available to us. C'mon, it's 
hardly usable and my monitor is 4480x2520 Retina!


* xf86-input-vmmouse doesn't support aarch64 either

The driver does not compile on aarch64 because it uses certain x86 
backdoor-like instructions to communicate with the VM host. I tried to 
port it to aarch64 but I've had no luck so far.

xf86-input-ws is a viable alternative but there is one caveat. VMware 
exposes a virtual mouse through USB:

[     1.657485] uhidev0 at uhub1 port 1 configuration 1 interface 0
[     1.657485] uhidev0: VMware (0x0e0f) VMware Virtual USB Mouse 
(0x0003), rev
1.10/1.02, addr 1, iclass 3/0
[     1.657485] ums0 at uhidev0: 16 buttons, W and Z dirs
[     1.657485] wsmouse0 at ums0 mux 0

By default it reports motion of mouse as absolute coordinates in (0, 0) 
- (32767, 32767) as if it were a touch panel, but our ums(4) treats it 
as relative coordinates for some unknown reason. As a result the mouse 
pointer in X.org quickly flies away outside of the display once you move 
your mouse! To work around the issue you can force VMware to report 
relative coordinates by adding the following line to your *.vmx file:

mouse.vusb.absDisabled = "TRUE"

This issue of course affects wsmoused(8) as well. It's on my TODO list 
to investigate it further.


* Xvnc from net/tigervnc was very unstable on this platform

So I considered running Xvnc and connecting to it from MacOS because I 
really needed to obtain a working desktop environment that fills my 
entire monitor with a decent resolution. The result was not so good. 
Xvnc frequently exited with status code 22 without leaving any messages 
or coredumps for no apparent reason. Tracing syscalls revealed that the 
problem always occurred when it received SIGALRM while doing some SIMD 
things at libpixman. When that happens it somehow corrupts the stack and 
setcontext(2) called by __sigtramp_siginfo_2 returns EINVAL, leading it 
to immediately exit the process instead of returning from a signal 
handler. I think I have found the cause and I'm going to file a PR with 
a patch after some more investigation.

In the meantime you can work around the issue by passing -dumbSched to 
Xvnc. It stabilizes Xvnc perfectly.


* firefox was extremely unstable on this platform

Now that I have a working desktop with 2240x1260 pixels, the next thing 
I need is Firefox. Firefox isn't exactly known for its stability on 
*any* OSes other than Windows, Linux, and MacOS but on this particular 
platform it was totally unusable. Whenever you open any website the tab 
crashes most of the time, and you'll have to spam-click the "Retry" 
button until it finally loads. And when you click any links in it the 
tab of course crashes again.

I've found a workaround for this as well. Replace /usr/pkg/bin/firefox 
with the following script, and it completely stops crashing:

#!/bin/sh
LD_PRELOAD=/usr/pkg/lib/firefox/libxul.so /usr/pkg/lib/firefox/firefox "$@"

I'm going to post a separate mail about the issue and my findings to 
tech-userlevel@ later.


Phew, okay now I can use everything I need on this virtual machine! I'm 
thinking of using QEMU to build GHC bootkits for amd64 platforms from 
now on, but my old Intel iMac was the only machine that ran 
Darwin/x86-64, which can cease to boot any time. When that happens I'll 
no longer be able to produce bootkits for this specific platform because 
QEMU cannot run Darwin AFAIK. I can probably build bootkits for 
Darwin/aarch64 instead.

[1]: https://github.com/depressed-pho/netbsd-src/tree/drm2-vmwgfx