Re: (Ab)using xenstored without Xen

[Juergen Gross <jgross@xxxxxxxx>]

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/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.
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

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature