Re: (Ab)using xenstored without Xen

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On 9 January 2023 07:40:06 GMT, Juergen Gross <jgross@xxxxxxxx> wrote:
>Sorry for the late answer, but I was pretty busy before my 3 week time off. :-)

No problem, I had lots of other things to work on, including my own time off. 
Hope you enjoyed it!

>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?

Not sure. I think we still need a privileged operation to "introduce" the 
client domain anyway, don't we?

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

Or use it for the new Xenless behaviour perhaps?

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

If anything it possibly makes some test cases a lot easier to run?