On 10/10/18 11:53 AM, Juergen Gross wrote:
> 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 <jgr...@suse.com>
>>> ---
>>> 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?
The admin may want to know, for example, that a hotplug in the guest failed.
-boris
>
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
