(Ab)using xenstored without Xen

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

I've been working on getting qemu to support Xen HVM guests 'natively'
under KVM:
https://lore.kernel.org/qemu-devel/20221216004117.862106-1-dwmw2@xxxxxxxxxxxxx/T/

The basic platform is mostly working and I can start XTF tests with
'qemu -kernel'. Now it really needs a xenstore.

I'm thinking of implementing the basic shared ring support on the qemu
side, then communicating with the real xenstored over its socket
interface. It would need a 'SU' command in the xenstored protocol to
make it treat that connection as an unprivileged connection from a
specific domid, analogous to 'INTRODUCE' but over the existing
connection.

However, there might be a bit of work to do first. At first, it seemed
like xenstored did start up OK and qemu could even connect to it when
not running under Xen. But that was a checkout from a few months ago,
and even then it would segfault the first time we try to actually
*write* any nodes. 

Newer xenstored breaks even sooner because since commit 60e2f6020
("tools/xenstore: move the call of setup_structure() to dom0
introduction") it doesn't even have a tdb_ctx if you start it with the
-D option, so it segfaults even on running xenstore-ls. And if I move
the tdb part of setup_structure() back to be called from where it was,
we get a later crash in get_domain_info() because the xc_handle is
NULL.

Which is kind of fair enough, because xenstored is designed to run
under Xen :)

But what *is* the -D option for? It goes back to commit bddd41366 in
2005 whch talks about allowing multiple concurrent transactions, and
doesn't mention the new option at all. It seems to be fairly hosed at
the moment.

Is it reasonable to attempt "fixing" xenstored to run without actual
Xen, so that we can use it for virtual Xen support?

Attachment: smime.p7s
Description: S/MIME cryptographic signature