Re: [Xen-devel] [PATCH] xen: drop writing error messages to xenstore

[Juergen Gross]

On 10/10/2018 17:09, Joao Martins wrote:
> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>> xenbus_va_dev_error() will try to write error messages to Xenstore
>> under the error/<dev-name>/error node (with <dev-name> something like
>> "device/vbd/51872"). This will fail normally and another message
>> about this failure is added to dmesg.
>>
>> I believe this is a remnant from very ancient times, as it was added
>> in the first pvops rush of commits in 2007.
>>
>> So remove the additional message when writing to Xenstore failed as
>> a minimum step.
>>
>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>> ---
>> I am considering removing the Xenstore write altogether, but I'm
>> not sure it isn't needed e.g. by xend based installations. So please
>> speak up in case you know why this write is there.
> 
> So this:
> 
> "This will fail normally and another message about this failure is added to dmesg."
> 
> Brings me to the question: What about {stub,driver}domains? Ideally you
> shouldn't be looking at domU's dmesg as a control domain no? I can't remember
> any other error node, but if something fails e.g. netfront fails to allocate an
> unbound event channel - how do you know the cause from the control domain
> perspective?
> 
> Irrespective of xend or not: isn't this 'error' node the only one that
> propagates error causes per device from domU?

What does it help you in dom0 if you have an error message in Xenstore
if a frontend driver couldn't do its job? Is there anything you can do
as a Xen admin?

I believe you'll have to look into the guest anyway, so there is no need
to have a message in the guest and one in Xenstore. The messages are
text only and can be evaluated only if you know guest internals.

blkfront for example prints an errno value into the message. I guess a
windows guest wouldn't do that, or it could use other values for the
same problem.


Juergen