Sorry for the late answer, but I was pretty busy before my 3 week time off. :-)
On 20.12.22 13:02, David Woodhouse wrote:
I've been working on getting qemu to support Xen HVM guests 'natively' under KVM: https://lore.kernel.org/qemu-devel/[email protected]/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.
Wouldn't an "unprivileged" socket make more sense?
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.
I guess this was some debugging add-on which hasn't been used for ages. I'm inclined to just remove the -D option.
Is it reasonable to attempt "fixing" xenstored to run without actual Xen, so that we can use it for virtual Xen support?
I don't see a major problem with that. The result shouldn't be too ugly, of course, and I don't see any effort on Xen side to test any changes for not breaking your use case. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
