Jan Beulich
2010-Feb-12 07:58 UTC
[Xen-devel] disallowed nesting of key handlers (c/s 20929)
Keir, I don''t think this is a good idea. In the course of analyzing issues with tmem we had at least one case where this restriction would have severely hindered debugging: The ''0'' handler wasn''t able to put a target vCPU to sleep (due to it spinning on a lock in the hypervisor), and only the subsequent ''d'' information really indicated what was going on. Generally expecting ''d'' to be issued first also doesn''t seem adequate since that may not produce output in the case of a pCPU spinning with interrupts disabled (whereas ''0'' in that case still has a chance to produce useful output). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Feb-12 08:01 UTC
Re: [Xen-devel] disallowed nesting of key handlers (c/s 20929)
Oh, and I also think the shared scratch buffer should be at least large enough to dump NR_CPUS and MAX_VIRT_CPUS wide bitmaps. Jan>>> "Jan Beulich" <JBeulich@novell.com> 12.02.10 08:58 >>>Keir, I don''t think this is a good idea. In the course of analyzing issues with tmem we had at least one case where this restriction would have severely hindered debugging: The ''0'' handler wasn''t able to put a target vCPU to sleep (due to it spinning on a lock in the hypervisor), and only the subsequent ''d'' information really indicated what was going on. Generally expecting ''d'' to be issued first also doesn''t seem adequate since that may not produce output in the case of a pCPU spinning with interrupts disabled (whereas ''0'' in that case still has a chance to produce useful output). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel