Re: [PATCH 9/9] xenstore: when running in mini-os use printk for diagnostic messages

[Juergen Gross <jgross@suse.com>]

On 15/12/15 15:06, Andrew Cooper wrote:
> On 15/12/15 12:55, Juergen Gross wrote:
>> On 15/12/15 13:52, Ian Campbell wrote:
>>> On Tue, 2015-12-15 at 13:47 +0100, Juergen Gross wrote:
>>>> On 15/12/15 13:31, Ian Campbell wrote:
>>>>> On Fri, 2015-12-11 at 16:47 +0100, Juergen Gross wrote:
>>>>>> Xenstore messages for diagnostic purposes are lost today in case
>>>>>> xenstore is running under mini-os instead in a dom0 daemon.
>>>>> Where does vfprintf end up under mini-os?
>>>> TBH: I just couldn't find it. I tried to get some diagnostics when
>>>> I started this work and couldn't find any place where the messages
>>>> would occur.
>>>>
>>>>>> Use printk of mini-os in this situation.
>>>>> and this now ends up on the console and (for a debug h/v) in the xen
>>>>> dmesg,
>>>>> is that right?
>>>> The console of the xenstore domain seems to be a little bit special, as
>>>> there is no component up to now writing the information needed to
>>>> connect xenconsoled to the xenstore domain. This could be the reason I
>>>> wasn't able to see any message printed via vfprintf. :-(
>>> That sounds probable.
>>>
>>>> So in the end it will be part of xen dmesg.
>>> Only for a debug=y Xen, not for a release build IIRC, unless you added some
>>> other privilege along with your new flag which I missed.
>> No, this is correct.
>>
>>>>  And this is where it should
>>>> be, as such messages will be needed in case of xenstore domain not
>>>> working properly. And I think it's console can be accessed by any means
>>>> only in case of a working xenstore. :-)
>>> An alternative would be init-xenstore-domain to daemonize and take on
>>> respoibility for consuming the console ring and throwing it into a file?
>> Interesting idea. I'll try this.
> 
> If the stubdomain could handle buffering of its ring for a while,
> xenconsoled could just be used.  Alternatively, have xenconsoled able to
> cope without xenstored while the xenstored stubdomain bootstraps itself.

This is a hen-and-egg problem.

Today xenconsoled relies on xenstore for connecting to the console
frontends. I think letting xenconsoled run without xenstore would
require quite some work in xenconsoled.

I suspect mini-os tries to initialize it's console frontend before
activating it's main thread and thus xenstore. So we would have to
re-init the xenstore domain's console after xenstore is capable to
add entries. I'm not sure the xenstore frontend of mini-os is
capable to talk to the backend directly instead via xenbus.

> IMO, it would be better to have just a single consoled, rather than
> having a stub running alongside.  A stub would necessarily need some
> negotiation with the main xenconsoled so they don't both map the console
> ring and play the part of consumer.

I think as long as the xenstore domain's console frontend isn't
creating xenstore entries the risk should be zero. I haven't checked
whether the information needed to get access to the console ring is
available without xenstore.

Looking at the alternatives I think trying to use xenconsoled just
normally via xenstore is the best solution. So we need a way to
handle the mini-os console frontend initialization, which should be
doable.


Juergen