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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel