Looks like this might be a Xwayland bug. Sommelier never receives a surface ID notify from Xwayland for this window, or any other windows while this app is running. These IDs are needed to bind an X window to a wayland surfaces and the window can't be made visible without.

If you kill the display-im6-q16 process, then things start working again.

I'll continue investigating.

I've investigated this more and here's what I found:

- display-im6-q16 decides that it's a good idea to create ~600 cursors when it starts up.
- Each cursor in Xwayland is backed by a virtio wayland buffer.
- When we reach close to 512 cursors, virtio wayland buffer allocation starts failing.
- At this point, all virtio wayland buffer allocations in the VM will fail. Doesn't matter if they are from the Xwayland or a new instance of sommelier.
- One of the crosvm processes on the host side will have around 512 open FDs when we're in this situation. The FD limit for the crosvm process is 1024 afaict and there's nothing in the log regarding allocation failures.

This is a good real world example that we need to handle much better. I think we should split this into a few separate bugs in order to make crostini handle these situations better. I'm suggesting this split:

1. Track down where in crosvm we fail. Improve logging and potentially increase some FD limit to make this less likely to happen.

2. After switching to DMABufs for xwayland, we get increased control over resource usage for xwayland buffers as we can chose shm vs dmabuf. This will allow us to introduce the following constraints:
  - Avoid the use of virtwl buffers for cursor pixmap.
  - Avoid the use of virtwl buffer if the pixmap is below a certain size.
  - (Maybe) Limit the number of virtwl buffers per X11 client.
    * To prevent one bad X11 client from causing poor performance for others.

3. Introduce a virtio wayland buffer limit for sommelier. This can be enforced by the master sommelier instance. The limit should be significantly less than crosvm limit in order to prevent one bad wayland client from ruining it for the rest. Note: it's fine if the client crashes when reaching this limit.

Good investigation, all SGTM

Latest version of my dmabuf patches for sommelier fixes this at the lowest level in Xwayland: https://chromium-review.googlesource.com/#/c/chromiumos/overlays/chromiumos-overlay/+/1034221

The way that works is that xwayland will limit dmabuf allocations to half of RLIMIT_NOFILE soft limit. Standard shared memory will be used for buffers once we reach this limit. This requires changing sommelier to use --shm-driver=virtwl instead of using noop for Xwayland. That's a performance regression today, but not a problem once we switch to dmabufs and that becomes the fast path.

I'll introduce a --max-open-files=FILES in sommelier next. This will allow us to set an appropriate soft limit for each wayland client. That will prevent one bad behaving wayland client from creating enough virtio buffers that other well behaving clients stop working.

The FD limit in Chrome is 8192. We don't want crosvm to get close to that but it might be good to increase the limit above the current 512.

How about the following?

Chrome: 8192
Crosvm: 2048
Sommelier: 1024

This way each linux app is limited to 1024 buffers and each VM instance is limited to 2048.

dgreid@, wdyt?

Those FD limits look like a good place to start. Should we set a limit for concierge, then let it set the limit for each VM instance it starts?

Sounds good. We have the KVM slot limit at ~500 today which will be the limiting factor for now so I'm going to use lower than necessary buffer limits inside the guest until that is fixed. Eventually, FDs in crosvm will be the limiting factor so getting that set explicitly to a value that makes sense is good.

 Issue 833121  has been merged into this issue.

<triage>Has this been fixed?</triage>

Yes, this is not a problem after switching to dmabufs.