How Qubes backend - frontend pairs are technically communicating?

e.g. Are you using ring buffers ?

Can you please document this in the architectural part of the Qubes documentation and website ?

1 Like

Thank you.

As a suggestion, would it be possible to explicit introduce in a few lines Qrexec concept both on

because it’s really a key architectural concept?


Welcome @ohault!

The documentation is written in the qubes-doc repository.

If you’re keen on adding those few lines, please do! (And if you paste the pull request link here, I’m happy to take a look at the change to help it through the review line.)

In general, if you find out that the change ends up larger than you’d initially thought, it may be worth opening an issue to discuss it with the team beforehand. All issues are centralized in the qubes-issues repository.

If you’re not familiar with GitHub but would like to update the docs, let me know and we can figure something out.

For additional context: @unman is currently assuming the documentatiom coordinator role. Small changes don’t usually require major coordination, but it may be useful to know nonetheless.


Qrexec looks like to be about Commands between domains, I’m not sure this mechanism is in charge of dataflow between Qubes OS backend and frontend concepts ?

The low level protocol is vchan, but there isn’t a lot of documentation on vchan

You can take a look at

and the mirage blog

This is probably closer to Xen then Qubes OS

Clarification question: are you after this kind of data flows?

qvm-copy relies on the qubes.FileCopy RPC that relies on qfile-unpacker:

Ok thank you, perfectly clear with " This protocol uses shared memory for inter-domain communication, i.e. between two VMs residing in the same Xen host, and uses Xen’s mechanisms – more specifically, [ring buffers] and [event channels]"

It would be worth mentioning this on the main architecture page.

There is only one problem because since Odissey, the architecture is intended to be hypervisor agnostic.