Okay the first issue was permissions. I was running crosvm directly, but needed o+rw on /run/chrome/wayland-0 to run crosvm as root.

Other issues:
1) Seccomp policy for wayland on arm needs an update. memfd_create was triggering a seccomp kill
2) After fixing #1, the VM no longer crashes but Wayland still fails
zachr's test program:
 ./virtwl -v -k
registry for interface wl_compositor
registry for interface wl_shm
registry for interface zwp_linux_dmabuf_v1
registry for interface wl_subcompositor
registry for interface wl_shell
registry for interface wl_output
registry for interface zxdg_shell_v6
registry for interface zcr_vsync_feedback_v1
registry for interface wl_data_device_manager
registry for interface wl_seat
registry for interface wp_viewporter
registry for interface wp_presentation
registry for interface zcr_secure_output_v1
registry for interface zcr_alpha_compositing_v1
registry for interface zcr_remote_shell_v1
registry for interface zaura_shell
registry for interface zcr_gaming_input_v2
registry for interface zcr_stylus_v2
registry for interface zcr_keyboard_configuration_v1
registry for interface zcr_stylus_tools_v1
registry for interface zcr_keyboard_extension_v1
registry for interface zwp_input_timestamps_manager_v1
failed to allocate shared fd: 19

zachr's test program, I built with gcc -lwayland-client -lrt -pthread -o virtwl virtwl.c

And ran as ./virtwl -v -k

Deleted: virtwl.c 21.8 KB

virtwl.c 21.8 KB View Download

Deleted: virtwl.h 1.3 KB

virtwl.h 1.3 KB View Download

I ran it without seccomp and with --disable-sandbox and got this error from crosvm when i started the container:

[ERROR:devices/src/virtio/wl.rs:835] failed to recv from vfd: VmBadResponse

I did some stracing and saw this:

10975 ioctl(8, KVM_SET_USER_MEMORY_REGION <unfinished ...>
10975 <... ioctl resumed> , 0xffceb430) = -1 EFAULT (Bad address)

And I think what's happening is that wayland is inserting some memory at some invalid location in the memory map -- really the arch code needs to be involved somewhere because it knows what the guest memory map should look like

also memfd_create seems to be getting an argument of 2 instead of 3 for some reason

10980 memfd_create(0x2, 0xd7c2714 /* MFD_??? */) = -1 EINVAL (Invalid argument)

re #5 -     


10980 memfd_create(0x2, 0xd7c2714 /* MFD_??? */) = -1 EINVAL (Invalid argument)

That's likely a specific hugepage shift value. Either this is a pre-4.14 kernel where these flags are not supported or it's an invalid hugepage shift which could by explained by the missing arch code.

(Sorry, I just saw this on accident.)

Ok, well I found the cause of the VmBadResponse -- I had a bug in the aarch64 implementation that was returning an address instead of a pfn.

So I corrected that and no longer get the VmBadResponse, however the test case is still failing with "failed ot allocate shared fd 19"

So I'm currently trying to debug that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosvm/+/5165cb7eece4e014fa4f3146591c20e8e4cc9c92

commit 5165cb7eece4e014fa4f3146591c20e8e4cc9c92
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Wed May 09 00:44:33 2018

crosvm: aarch64: fix lack of shifting for base_dev_pfn

This is a pfn (page-frame number) not a raw address, so we need to
shift it right by 12.

BUG= chromium:840048 
TEST=manual test on kevin with virtio wayland and --disable-sandbox,
should not get "failed to recv from vfd: VmBadResponse" message

Change-Id: I788712ec7b9b3e9b4ada481d62a5f2ae1624e929
Reviewed-on: https://chromium-review.googlesource.com/1049060
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/5165cb7eece4e014fa4f3146591c20e8e4cc9c92/aarch64/src/lib.rs

Ok, it looks underlying failure is the call to memfd_create in the virtio_wl when it tries to create a shared memory segment. 

It looks like there's some custom code to define the call the memfd_create in sys_util/src/shm.rs that's only suitable for x86_64.  I created a different version for arm and the virtwl test program seems to work, and incidentally it also seems to work on x86_64, so I'm going to put up a cL for that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosvm/+/17bd06f65b51d1f5b484062ce3d994b576015fba

commit 17bd06f65b51d1f5b484062ce3d994b576015fba
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Wed May 09 11:33:14 2018

sys_util: SharedMemory: fix signature for memfd_create syscall

The signature for this system call was wrong, but somehow managed to
work on x86_64.  This should fix it to work on all architectures.

BUG= chromium:840048 
TEST=build_test passes
TEST=virtio wayland works on ARM

Change-Id: I295548357f688be4772e65991fb65178ead3b1e8
Reviewed-on: https://chromium-review.googlesource.com/1050915
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>

[modify] https://crrev.com/17bd06f65b51d1f5b484062ce3d994b576015fba/sys_util/src/shm.rs

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosvm/+/0ac9254f9ae496eba2e95d0c222071fe0bd07a26

commit 0ac9254f9ae496eba2e95d0c222071fe0bd07a26
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Wed May 09 11:33:14 2018

crosvm: aarch64: fix truncate on wayland policy

Like block_device, also needs to use ftruncate64 instead of ftruncate.

BUG= chromium:840048 
TEST=manual test of graphics on kevin

Change-Id: Ib24b12fd681c96ecc2fec796fe480e94a96a0626
Reviewed-on: https://chromium-review.googlesource.com/1050916
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>

[modify] https://crrev.com/0ac9254f9ae496eba2e95d0c222071fe0bd07a26/seccomp/aarch64/wl_device.policy

virtwl should work after these two CLs land:
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1050916
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1050915


however, it looks like sommelier is still unhappy but maybe we should open another bug for that?