[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine
On 04/09/12 10:40, Jan Beulich wrote: >>>> 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 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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |