R4.1: Adapt to new gui protocol version using grant refs

[HW42]

No description provided.

[HW42]

Depends on QubesOS/qubes-gui-common#2 and requires QubesOS/qubes-gui-daemon#21 in dom0.

[marmarek]

🎉

[HW42]

With the new grant based memory sharing you can run easily in the default limits for allocated/mapped grants. Inside a domain there's /sys/module/xen_gntdev/parameters/limit and /sys/module/xen_gntalloc/parameters/limit. AFAIU they are only to avoid DoS by user space inside the domain so can be simply set to something very high (like here). Any opinion about the concrete value?

More tricky is the global limit controlled by gnttab_max_frames. Default is 32. I have run into this limit at least sometimes. For testing I arbitrarily set it to 128 and had no issues so far. But with more intense usage this might also be not enough.

[marmarek]

What exactly happen (form user POV) when you run into this limit? Is closing some window enough to get the VM back to working state?

As for actual value, I'd say something allowing handling N windows of maximum supported size, where N, lets say 4.

[cfcs]

I think I recall @reynir also having problems with gnttab_max_frames (on the host side)? @reynir, do you remember the details?

@marmarek: would that mean it would be possible to run 8 windows at half size?

[marmarek]

@cfcs old GUI protocol didn't used grant references, so that's unlikely. There was a similar problem in mini-os + mirage vchan implementation (hardcoded limit), but that's mostly unrelated to GUI.

As for count of windows - yes.

[cfcs]

@marmarek that was the problem I was thinking of, thank you. :)

Re: Window size: 4 seems a bit limiting, at least I frequently have more than 4 full-screen windows open. If the default is to be conservative, any chance this could be made a configuration option?

[marmarek]

Re: Window size: 4 seems a bit limiting, at least I frequently have more than 4 full-screen windows open. If the default is to be conservative, any chance this could be made a configuration option?

Note that it's in practice about summary surface, expressed as number of windows of maximum supported resolution, not just number of fullscreen windows. It would be N (proposed 4) windows of _maximum supported resolution_, which is currently 16384x6144. If you have lower resolution, then you could have much more fullscreen (or else) windows. If that limit will become an issue in the future, we could raise it then, assuming more RAM will be a common thing at that time.

[HW42]

Fixed the domid != 0 case ;]

That's Xephyr (nested X server) running in a domain named gui-domain (with blue border from dom0). In gui-domain there's a qubes-guid running using the Xephyr server. This qubes-guid draws those green borders around the window from another domain. The terminal window itself doesn't get a border since there's no window manager running there which would need to draw the border.

cc @rootkovska

[cfcs]

@marmarek Ahh, I thought it was of the current resolution. That constant definitely works for me. :)

[cfcs]

shouldn't this have fstack-protector-all, ro-relocations etc?

[marmarek]

rpm already define them, it's just about using CFLAGS/LDFLAGS. I'll add it here too.

[marmarek]

Missing error handling (was already missing in the old version).