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

[Juergen Gross <jgross@suse.com>]

On 15/12/15 16:01, Andrew Cooper wrote:
> On 15/12/15 14:57, Juergen Gross wrote:
>> 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.
> 
> All console information (from the domains point of view) is provided in
> the shared info page for PV, or via HVM Params for HVM.

Aah, of course. This information is put by the domain builder into the
start_info page. So it is available to init-xenstore-domain which could
then write the corresponding xenstore entries.

> The toolstack is responsible for stashing the same information in
> xenstore so xenconsoled can connect.  (This is somewhat problematic as
> the two can get out of sync and nothing notices.)

Toolstack would be init-xenstore-domain in this case. Doing this would
mean xenconsoled is just working, I guess. I'll have a try then.


Juergen