qemu-stubdom<=>dom0 interface changes

[Jean-Philippe Ouellet]

Hello,

I see vmm-xen-stubdom-linux commit 93bf371 [1] turning what was
previously a rather simple dom0<=>stubdom command interface over
xenstore into a full bidirectional QMP<=>vchan proxy, permitting QMP
parsing in dom0.

I also see several commits setting up stubdom serial consoles as a
transport for vm save/restore, as well as [2].

Rather than speculate, I figured I'd just ask... what is ultimately
the desired use case which necessitates this? And does it really
require multi-step interaction over a not-quite-trivial protocol with
response processing in dom0?

Regards,
Jean-Philippe

[1]: https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/commit/93bf371
[2]: https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02225.html

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Jun 25, 2019 at 12:05:25AM -0400, Jean-Philippe Ouellet wrote:
> Hello,
>
> I see vmm-xen-stubdom-linux commit 93bf371 [1] turning what was
> previously a rather simple dom0<=>stubdom command interface over
> xenstore into a full bidirectional QMP<=>vchan proxy, permitting QMP
> parsing in dom0.
>
> I also see several commits setting up stubdom serial consoles as a
> transport for vm save/restore, as well as [2].
>
> Rather than speculate, I figured I'd just ask... what is ultimately
> the desired use case which necessitates this? And does it really
> require multi-step interaction over a not-quite-trivial protocol with
> response processing in dom0?

The general intention is to unify qemu-upstream stubdomain between
projects - have it in upstream Xen, and also share the same code base
with OpenXT. Right now, there are multiple implementations, each
maintained mostly separately by different projects (although we do
exchange patches with OpenXT). Having new stubdomain upstream would also
allow adding it to Xen regression test infrastructure, so - less
surprise breakage in new Xen versions.
But for this to happen, it needs to be possible to use features offered
by upstream Xen. This include some kind of access to QMP (device
hotplug, migration, etc).
I have considered[3] going xenstore way for other commands, but it doesn't
really scale, if you need to implement 10+ more commands.

BTW, OpenXT's own implementation expose QMP over v4v (their vchan-like
interface, now named "argo" and upstreamed already) for a long time.

JSON-based protocol, parsed in C (libxl) isn't the best possible idea,
but also we are not really forced to use it there. Libxl connects to it
only if it wants to issue some command (so, qemu can't send arbitrary
data to libxl at arbitrary time), and we can easily disable most/all of
it from libxl side (similar as we disable dom0's qemu instance, used for
VNC server, or qdisk). The thing that is currently enabled in our build is PCI
passthrough related orchestration, which happens before the target
domain is started, so it doesn't have a chance to attack qemu at this
point yet.

As for vm save/restore, it is forward port of similar mechanism from
mini-os based stubdomain. From dom0 perspective, it is an opaque blob
not parsed in any way. Just sent back to qemu on restore.

> Regards,
> Jean-Philippe
>
> [1]: https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/commit/93bf371
> [2]: https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02225.html

[3]: https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg00067.html

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl0SFQwACgkQ24/THMrX
1yxyXwf/XCwE9tkDlptcvZptkZxYI+QmSVYnE181CKifAlx6Rt+v43DOGZK2Mr6p
nGt5JLMwHzp2uQnbhJEh4mI3dIQvBMFvnAE3f+kBhs5DDl/rqcJQDT5nzyo8xQM0
S6ZMrX8QCdA9EF1U7n2pV5ecqEIaGPWNgvz2m9jCqrRQhNVySWAUoChwiVJ5J+QS
9Qj9khQbmvBJfClBYtOHtPqBEB6kyWGY4HXN1ige+nBAYl0/aURwAd4bA4xLo0Zk
TK9lQmHkSNom52mQbk1klTVPvAyPhgSlUdEKCGyc/JuC8lCFDkJ8m0Hqs5ZQmV8x
kNCcj6lXBM/MxAP2W+zsWlDBLeF7MA==
=M1cF
-----END PGP SIGNATURE-----