I started this issue to discuss what is required to get the gui-(daemon,agent} implemented. I know your plan is to start working on this at some point and you mentioned upstream changes may be required after some brief discussions you had with @marmarek. I am not sure if those discussions were in relation to adding libvchan_setup_connection and libvchan_cleanup_connection or something else within gui-agent.
Are changes required for libvchan?
The discussion in issue #1 talked about implementing some features within both libkvmchan and upstream Qubes libvchan. Since that time you have made various changes to libkvmchan so I am wondering is those changes are still required to get the gui-agent working. I guess that is up to you and @marmarek to figure out.
Are changes required for libkvmchand?
Does libkvmchand already have the ability to handle shared memory or is something else required like kernel drivers. When researching ivshmem I can across the LookingGlass site which captures the GUI frame buffer and shares its output with the host or other guest VM using ivshmem. They have a kernel module that could serve as an example.
As you may have a busy schedule, I am willing to assist implementing any changes to Qubes components I can as well as any work required to get shared memory working for the gui-agent running in a KVM environment.
I had started gathering reference material to assist you but after coming across the work you completed within the qubes-gui-daemon repo it appears you have a good handle on what is required so I'll just post what I have so far in hopes it may be helpful to someone. My comments are my understanding of how the gui-{daemon,agent} currently communicates.
gui-agent-linux (qubes-gui-agent) Overview
On boot within the multi-user.target qubes-gui-agent.service is responsible for preparing and setting up a graphical session for the default user using an Xorg or Xephyr (if guivm-gui-agent qubes-service enabled) server. For our use case we will only be initializing the Xorg server.
When /usr/bin/qubes-gui is executed, it connects using port 6000 to qubes-guid on the host. After connecting it sets some environment variables after requesting some Xorg configuration details (screen width, height, depth and memory as well as the $GUI_DOMID), and then calls /usr/bin/qubes-run-xorg to start the default users x-windows session. Using the environment variables set by qubes-gui, the qubes-run-xorg script creates a Xorg configuration file '/etc/X11/xorg-qubes.conf' from a template '/etc/X11/xorg-qubes.conf.template' and then calls /usr/bin/qubes-gui-runuser to start the x-server as the default user add a graphical session through PAM.
During x-windows startup various other qrexec serverices are started such as qrexec-fork-server, and qrexec-policy-agent. Note that for the host to be able to communicate with the guest VM using Qubes tools such as qvm-run --pass-io fc32 'cat /home/user/log' > log, it is required that the qrexec-fork-server has been started as the default user.
I started this issue to discuss what is required to get the gui-(daemon,agent} implemented. I know your plan is to start working on this at some point and you mentioned upstream changes may be required after some brief discussions you had with @marmarek. I am not sure if those discussions were in relation to adding
libvchan_setup_connectionandlibvchan_cleanup_connectionor something else within gui-agent.Are changes required for libvchan?
The discussion in issue #1 talked about implementing some features within both
libkvmchanand upstream Qubeslibvchan. Since that time you have made various changes tolibkvmchanso I am wondering is those changes are still required to get thegui-agentworking. I guess that is up to you and @marmarek to figure out.Are changes required for libkvmchand?
Does libkvmchand already have the ability to handle shared memory or is something else required like kernel drivers. When researching
ivshmemI can across the LookingGlass site which captures the GUI frame buffer and shares its output with the host or other guest VM usingivshmem. They have a kernel module that could serve as an example.As you may have a busy schedule, I am willing to assist implementing any changes to Qubes components I can as well as any work required to get shared memory working for the gui-agent running in a KVM environment.
I had started gathering reference material to assist you but after coming across the work you completed within the
qubes-gui-daemonrepo it appears you have a good handle on what is required so I'll just post what I have so far in hopes it may be helpful to someone. My comments are my understanding of how the gui-{daemon,agent} currently communicates.gui-agent-linux (qubes-gui-agent) Overview
On boot within the multi-user.target qubes-gui-agent.service is responsible for preparing and setting up a graphical session for the default user using an Xorg or Xephyr (if guivm-gui-agent qubes-service enabled) server. For our use case we will only be initializing the Xorg server.
The qubes-gui-agent service unit file performs some initial pre-configuration then executes /usr/bin/qubes-gui with options contained within '/var/run/qubes-service-environment' that were set within the /usr/lib/qubes/qubes-gui-agent-pre.sh pre-configuration script.
When /usr/bin/qubes-gui is executed, it connects using port 6000 to qubes-guid on the host. After connecting it sets some environment variables after requesting some Xorg configuration details (screen width, height, depth and memory as well as the $GUI_DOMID), and then calls /usr/bin/qubes-run-xorg to start the default users x-windows session. Using the environment variables set by
qubes-gui, thequbes-run-xorgscript creates a Xorg configuration file '/etc/X11/xorg-qubes.conf' from a template '/etc/X11/xorg-qubes.conf.template' and then calls /usr/bin/qubes-gui-runuser to start the x-server as the default user add a graphical session through PAM.During x-windows startup various other
qrexecserverices are started such asqrexec-fork-server, andqrexec-policy-agent. Note that for the host to be able to communicate with the guest VM using Qubes tools such asqvm-run --pass-io fc32 'cat /home/user/log' > log, it is required that theqrexec-fork-serverhas been started as the default user.