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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.12 at 10:54, Keir Fraser <keir@xxxxxxx> wrote:
> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@xxxxxxxx> 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


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