Generalize GUI daemon's xc_map_foreign_pages()

[rootkovska]

A few changes will be needed to allow to run gui-daemon in non-Dom0 VM when used in "true GuiDom" mode.

Some of these changes (especially with regards connection establishing between other AppVMs and GuiDom) should be resolved as part of #833. However, completing of #833 will likely not solve the problem with guid relying on the Xen's xc_map_foreign_pages (see https://github.com/QubesOS/qubes-gui-daemon/blob/v3.2.8/shmoverride/shmoverride.c#L76), which we need to solve for use with true GuiDom implementation.

[rootkovska]

While touching the GUID and reworking the xc_map_forgein_pages() for work with GUI domain, we should also make an effort to generalize this call to allow for future architectures not based on Xen. Ideally not even based on shared-memory-based hardware architectures.

Here the primary observation is that our GUI protocol already comprises two channels:

1. The metadata channel (e.g. MSG_CONFIGURE, etc) about configuration and positioning of windows, damage notifications, human input.
2. The actual data (i.e. pixels) channel, currently realized by xc_map_foreign_page as zero-copy memory sharing between the AppVM and Dom0, aided by the MSG_MFNDUMP messages flying over the meta channel.

So, the generalized version of the protocol should allow for providing independent implementations of this data channel (e.g. over network).

[marmarek]

Can you use full "GUI daemon" name? GUID means "globally unique identifier".

[marmarek]

For the record, this is implemented in:
QubesOS/qubes-gui-daemon#21
QubesOS/qubes-gui-common#2
QubesOS/qubes-gui-agent-linux#34
(missing qubes-gui-agent-xen-hvm-stubdom)

[jpouellet]

@marmarek can this be closed since QubesOS/qubes-gui-agent-xen-hvm-stubdom@e341ebd?

[marmarek]

In theory there is one more component needed to be ported - gui-agent-windows. But it's kind of unmaintained...