[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



Hello Keir,

Tuesday, September 4, 2012, 10:11:42 AM, you wrote:

> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:

>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of 
>>>> spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

> 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.

Is it necessary for this case to let it be a key-handler for which one can't 
specify parameters to limit the output ?

In this case both hypervisor and kernel are running fine, so a interface via 
say "xl debug" should be perfectly fine and providing parameters should be 
possible ?

>>  -- Keir
>> 
>> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.