Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/09/12 10:40, Jan Beulich wrote:
>>>> On 04.09.12 at 10:54, Keir Fraser <keir@xen.org> wrote:
>> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>>> My pragmatic take would be that: (a) Really long-running handlers that want
>>>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>>>> we should consider if they are worthwhile at all; (b) moderately
>>>> long-running but useful handlers which nonetheless take a long time to dump
>>>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>>>> into a supplied memory buffer.
>>> At a first glance that sounds like a viable option, assuming that
>>> the bulk of the time otherwise is being spent actually getting the
>>> data out through the serial line. But if the long-running-ness is
>>> in the nature of the keyhandler itself, then this wouldn't help
>>> much though. And I'd be afraid that ought to be the common
>>> case when not running with sync_console, since actual serial
>>> output happens asynchronously and hence shouldn't affect the
>>> latency of the keyhandler's completion too much.
>> Well then, have we actually seen problems with async serial output, a
>> decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
>> we don't have a problem to be solved. :)
> To a degree - we have seen (large) systems becoming unstable
> after making use of these keys, but obviously people were
> instructed to use the keys because the system already had some
> sort of problem (e.g. were dead locked on some spin lock, and
> after use of the debug keys additionally got their time screwed
> up).
>
> The 'o' key here just gets this to the extreme, which is why I'm
> wondering whether it was a good decision to add it in the first
> place. And the same would apply to EPT's 'D' key. The more that
> these keys would presumably be used when a guest had a
> problem, yet their use could render the whole system dead
> (whereas 'd' and '0' generally get used when the host is in a
> bad state already). Perhaps a minimal step would be to build/
> enabled these only in debug=y builds? But really this functionality
> should be exposed _only_ through the tools (similar to xenctx
> and lsevtchn) imo (and along those lines I think 'e' should only
> dump Dom0's event channels).
>
> Jan

I would disagree with that final part.  I have lost count of the number
of times that I have used the 'e' debug key to diagnose a problem with a
locked up system where dom0 was not necessarily accessible.  Getting all
domains information is very useful, even if it can be long at times. 
The times when the length is a problem are also the times when the
server is broken to a point that it is not a problem people are
concerned with.

~Andrew

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

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com